Lipp - VPN Virtuelle Private Netzwerke

VPN Virtuelle Private Netzwerke
Manfred Lipp
VPN Virtuelle Private Netzwerke

Aufbau und Sicherheit
An imprint of Pearson Education

Mnchen Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam
Die Deutsche Bibliothek - CIP-Einheitsaufnahme Ein Titeldatensatz fr diese Publikation ist bei Der Deutschen Bibliothek erhltlich.
Die Informationen in diesem Produkt werden ohne Rcksicht auf einen eventuellen Patentschutz verffentlicht. Warennamen werden ohne Gewhrleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit grter Sorgfalt vorgegangen. Trotzdem knnen Fehler nicht vollstndig ausgeschlossen werden. Verlag, Herausgeber und Autoren knnen fr fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung bernehmen. Fr Verbesserungsvorschlge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulssig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwhnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie zum Schutz vor Verschmutzung ist aus umweltfreundlichem und recyclingfhigem PE-Material.
10 9 8 7 6 5 4 3 2 1 05 04 03 02 01 ISBN 3-8273-1749-5 2001 by Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Strae 1012, D-81829 Mnchen/Germany Alle Rechte vorbehalten Einbandgestaltung: atelier fr gestaltung n.&h., Niesner & Huber, Wuppertal Lektorat: Rolf Pakendorf, rpakendorf@pearson.de Korrektorat: Friederike Daenecke, Zlpich Herstellung: Anna Plenk, aplenk@pearson.de Satz: reemers publishing services gmbh, Krefeld (www.reemers.de) Druck und Verarbeitung: Media Print, Paderborn Printed in Germany
Inhaltsverzeichnis
Vorwort Aufbau Danksagung 1 Virtuelle private Netzwerke 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Was ist ein VPN? Geschichte und Technologien Warum VPNs? Rahmenbedingungen fr den Einsatz Der VPN-Markt IP-VPNs und das Internet Entwicklungen und Ausblicke 15 16 17 19 19 20 24 26 28 30 33 37 37 41 42 43 44 46 47 48 50 52 53 53 53 54 55 55 56 56 57 57
2 VPN-Typen 2.1 2.2 2.3 2.4 Remote-Access-VPN Branch-Office-VPN Extranet-VPN VPN-Service-Provider 2.4.1 2.4.2 2.5 2.5.1 2.5.2 2.5.3 IP-VPN-Dienste Layer-2-VPN-Dienste Virtual Local Area Network (VLAN) VLANs nach IEEE802.1q IP-Tunneling
Intranet-VPN
3 Anforderungen an VPNs 3.1 Sicherheit 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 Datenvertraulichkeit Schlsselmanagement Paket-Authentifizierung Datenintegritt Benutzer-Authentifizierung Benutzer-Autorisierung Schutz vor Sabotage Schutz vor unerlaubtem Eindringen
Inhaltsverzeichnis
3.2
Verfgbarkeit 3.2.1 3.2.2 3.2.3 Die Verfgbarkeit von Whlverbindungen Die Verfgbarkeit von permanenten Verbindungen Die Verfgbarkeit von IP-VPNs Die Performance von Whlverbindungen Die Performance von permanenten Verbindungen Die Performance von IP-VPNs Einfhrung in QoS-Konzepte Quality-of-Service bei Whlverbindungen Quality-of-Service bei permanenten Verbindungen Quality-of-Service im IP-Protokoll Die IP-Differentiated-Services-Architektur (DiffServ) Differentiated Services in IP-VPNs
59 59 60 60 61 61 61 62 62 63 66 67 69 69 74 75 76 76 80 82 83 85 87 87 87 90 91 93 95 95 95 97 97 99
3.3
Performance 3.3.1 3.3.2 3.3.3
3.4
Quality-of-Service (QoS) 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6
3.5 3.6
Skalierbarkeit und Migrationsfhigkeit Integration in existierende Netze 3.6.1 3.6.2 Management Sicherheit
3.7 3.8 3.9
Koexistenz zu traditionellen WAN-Strukturen Adressmanagement Interoperabilitt
4 Sicherheitstechnologie 4.1 Sicherheit in VPNs 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 4.2.2 4.2.3 4.2.4 Sicherheit in Unternehmensdatennetzen Die Sicherheit von virtuellen privaten Netzen Datenvertraulichkeit Sicherheit in der Netzwerkschicht mit IP Security Benutzer-Authentifizierung Geschichtliches Datenvertraulichkeit Verschleierung und Verschlsselung Die Kunst der Kryptoanalyse
Die Grundlagen der Kryptographie
Inhaltsverzeichnis
4.2.5 4.2.6 4.3 4.4
Einfhrung in die Kryptographie Verschlsselungsverfahren
101 108 113 114 116 117 118 120 120 122 123 124 126 126 128 129 129 131 132 136 138 140 141 142 143 143 145 146 146 146 147 147 148 148
Symmetrische Verschlsselungsverfahren Der Data Encryption Standard (DES) 4.4.1 4.4.2 4.4.3 4.4.4 Ein berblick ber DES Die DES-Schlsseltransformation Die DES-Funktion Die DES-Entschlsselung
4.5 4.6 4.7
Triple-DES Cipher Block Chaining (CBC) 4.6.1 4.7.1 4.7.2 4.7.3 4.7.4 Die Funktionsweise von CBC AES-Software-Implementierung AES-Hardware-Implementierung And the winner is . Rijndael Die kurze Geschichte der Public-Key-Kryptographie Das Grundprinzip der Public-Key-Kryptographie Mathematische Grundlagen Ausblick: Der Advanced Encryption Standard
AES-Geschwindigkeit und Optimierungsmglichkeiten 127
4.8
Asymmetrische Verschlsselungsverfahren 4.8.1 4.8.2 4.8.3
4.9
Das Diffie-Hellman-Verfahren 4.10.1 4.11.1 4.11.2 4.11.3 Zufallszahlen Algorithmen Keyed Hashing Hash-based Message Authentication Code (HMAC)
4.10 Das RSA-Verfahren 4.11 Hashfunktionen
5 Authentifizierung 5.1 Mglichkeiten der Authentifizierung 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 Starke und schwache Authentifizierung Wissensbasierende Authentifizierung Besitzbasierende Authentifizierung Kombinationsverfahren Biometrik Verfahren mit Einmal-Token
Inhaltsverzeichnis
5.2
Digitale Signaturen und digitale Zertifikate 5.2.1 5.2.2 Funktionsweise von digitalen Signaturen Digitale Zertifikate nach ITU-X.509-Standard PAP und CHAP RADIUS LDAP Chipkarten Vertrauensmodelle Die Certificate Authority (CA) Die Registration Authority (RA) Zertifikat-Management Die Qual der Wahl: ffentliche oder private Zertifikate Das Signaturgesetz und die EU-Richtlinie
150 150 153 155 155 157 160 160 162 162 164 164 164 166 167 169 170 170 171 172 172 172 173 174 176 176 178 179 180 180 181 183 183 184
5.3
Authentifizierungssysteme und -protokolle 5.3.1 5.3.2 5.3.3 5.3.4
5.4
Public Key Infrastructure (PKI) 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6
6 Tunneling-Technologien im berblick 6.1 Tunneling-Modelle 6.1.1 6.1.2 6.1.3 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.5 6.6 Das Intra-Provider-Modell Das Provider-Enterprise-Modell Das Ende-zu-Ende-Modell Layer-2-Tunneling-Protokolle Layer-3-Tunneling-Protokolle Multi Protocol Label Switching (MPLS) IP Security Protocol (IPSec) im Tunnel-Modus Layer 2 Tunneling Protocol (L2TP) Layer 2 Forwarding (L2F) Point-to-Point Tunneling Protocol (PPTP)
Tunneling-Protokolle
Standardisierte Tunneling-Protokolle
Nicht standardisierte Protokolle
Verschachtelte Tunneling-Protokolle Welches Protokoll fr welchen Zweck? 6.6.1 6.6.2 Gegenberstellung Auswahlkriterien
Inhaltsverzeichnis
7 Das IP-Security-Protokoll (IPSec) 7.1 IP Security im berblick 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.2 7.2.1 7.2.2 7.2.3 7.3 7.3.1 7.3.2 7.4 7.5 Paketintegritt Paketauthentifizierung Paketvertraulichkeit Verkehrsflussvertraulichkeit Schutz vor wiederholtem Senden von Paketen (Replay-Angriff) Schutz vor weiteren Denial-of-Service-Angriffen Datenverschlsselung in IPSec Integrittsprfung und Authentifizierung in IPSec Schutz vor Replay-Angriffen Die IPSec-Architektur Die aktuelle IPSec-Standardisierung
187 188 188 189 189 189 190 190 191 191 193 194 196 196 197 199 201 201 202 203 203 203 204 205 205 205 205 205 206 209 214 214 215 215 219
Kryptographische Verfahren in IPSec
Die IPSec-Standardisierung
Die IPSec-Sicherheitsassoziation Die IPSec-Security-Policy 7.5.1 7.5.2 Die Security Policy in IPSec Die IPSec-Selektoren Tunnelmodus Transportmodus Gateway-zu-Gateway Host-zu-Gateway Host-zu-Host Die Paketverarbeitung in IPSec Das Authentication-Header-Protokoll (AH) Das Encapsulating-Security-Payload-Protokoll (ESP) Betriebssystemebene, IPSec-Stack Bump-in-the-Stack (BITS)
7.6
IPSec-Betriebsmodi 7.6.1 7.6.2
7.7
IPSec-Einsatzszenarien 7.7.1 7.7.2 7.7.3
7.8
IPSec-Protokolle 7.8.1 7.8.2 7.8.3
7.9
IPSec-Implementierungen 7.9.1 7.9.2
7.10 Betrachtungen zur IPSec-Performance 7.11 Zuknftige Entwicklungen
Inhaltsverzeichnis
8 Das Internet-Key-Exchange-Protokoll 8.1 8.2 Das Henne-Ei-Problem ISAKMP 8.2.1 8.2.2 8.2.3 8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 8.3.8 8.3.9 8.3.10 8.3.11 8.3.12 8.3.13 8.4 8.4.1 8.4.2 8.5 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 8.5.6 8.6 8.6.1 8.6.2 8.6.3 Die Sicherheit von ISAKMP Der ISAKMP-Header Der generische ISAKMP-Nutzdaten-Header Die Sicherheitsassoziation-Payload Die Proposal Payload Die Transform Payload Key Exchange Payload Identification Payload Certificate Payload Certificate Request Payload Hash, Signature und Nonce Payload Notification Payload Delete Payload Vendor ID Payload Die ISAKMP-Phasen Die ISAKMP-Austauschvorgnge Die Oakley-Gruppe-1 Die Oakley-Gruppen 2 bis 5 Perfect Forwarding Secrecy Die Attribute einer IPSec-Sicherheitsassoziation Die Attribute einer ISAKMP-Sicherheitsassoziation IKE-Sicherheitsverfahren Die Schlsselerzeugung in IKE IKE-Authentifizierung Authentifizierung mit Pre-Shared Key Authentifizierung mit digitaler Signatur Authentifizierung mit Public-Key-Verschlsselung (RSA)
221 221 222 223 228 231 232 232 233 233 234 235 235 236 237 238 239 240 241 241 243 243 244 244 245 245 247 250 251 254 256 256 260 261
ISAKMP-Nutzdaten
Das Oakley Key Determination Protocol
Der Aufbau von IKE
Der IKE Main Mode
Inhaltsverzeichnis
8.6.4 8.7
Authentifizierung mit revidierter Public-KeyVerschlsselung (RSA) Authentifizierung mit Pre-Shared-Secret Authentifizierung mit digitaler Signatur Authentifizierung mit standardisierter und revidierter Public-Key-Verschlsselung
263 265 267 269 269 269 272 273 277 277 278 278 280 282 284 285 286 289 289 289 292 293 295 298 300 303 305 309 309 310 310 312 314 315
Der IKE Aggressive Mode 8.7.1 8.7.2 8.7.3
8.8 8.9
Der IKE Quick Mode Die Performance von IKE 8.9.1 IKE und Hardwarebeschleuniger
9 Das Layer 2 Tunneling Protocol 9.1 Das Point-to-Point Protocol (PPP) 9.1.1 9.1.2 9.1.3 9.1.4 9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 9.2.7 9.2.8 9.2.9 9.2.10 9.3 9.4 PPP-Remote-Access PPP-Komponenten PPP-Steuerungsprotokolle und -Dienste PPP-Verbindungsaufbau Virtueller Remote Access mit L2TP PPP-Session-Verteilung in L2TP Die Rolle des LAC (L2TP Access Concentrator) Die Rolle des LNS (L2TP Network Server) Betrachtungen zur Performance von L2TP L2TP-Tunneling-Modelle L2TP-Paketformate L2TP Attribute Value Pairs (AVP) Auf- und Abbau von Tunneln und Calls in L2TP L2TP-Benutzer-Authentifizierung
PPP-Tunneling mit L2TP
Die Sicherheit von L2TP IPSec secured L2TP
10 VPN-Design 10.1 Ein VPN ist auch nur ein Netzwerk 10.2 Die Planung 10.3 Die Ist-Aufnahme 10.3.1 10.3.2 10.3.3 Technische Aspekte Betriebswirtschaftliche Aspekte Sicherheit
Inhaltsverzeichnis
10.4 Der Sollzustand 10.4.1 10.4.2 10.4.3 10.4.4 Der unvermeidliche (?) Bruch Randbedingungen Technische Aspekte Betriebswirtschaftliche Aspekte
316 316 317 319 321 322 322 325 325 326 327 328 329 330 341 342 343 344 346 351 352 353 356 356 359 360 361 362 363 364 364 364 366 370 370 372
10.5 Die bergangsphase 10.6 Die Sicherheitsstrategie 10.7 Auswahl der VPN-Technologie 10.7.1 10.7.2 VPN-Typ Tunneling-Protokolle
10.8 Ermitteln der QoS-Parameter 10.9 Die Realisierung 10.9.1 10.9.2 10.9.3 10.9.4 10.9.5 10.9.6 10.9.7 10.9.8 10.9.9 Routing im VPN Remote Access Kleine Auenstellen und Heimbros Skalierbarkeit Redundanz und Ausfallsicherheit Durchsatz und Quality-of-Service Sicherheitsstrategie und Firewalls Authentifizierungsverfahren Die Auswahl von Service Providern
10.9.10 Service Level Agreements 10.10 Beispiele 10.10.1 Remote-Access-VPN 10.10.2 Branch-Office-VPN 10.10.3 IP-VPN-Service eines ISP 11 Auswahl der VPN-Komponenten 11.1 VPN, Feature oder dediziert? 11.2 Performance 11.2.1 11.2.2 11.2.3 Eigene Messungen Verffentlichte Testberichte Beurteilungskriterien
11.3 Die Herstellerauswahl 11.4 Die Auswahl der VPN-Komponenten 11.4.1 11.4.2 Das Beispielnetzwerk Allgemein
Inhaltsverzeichnis
11.4.3 11.4.4 11.4.5 11.4.6 11.4.7 11.4.8 11.4.9
Leistung Schnittstellen Tunneling-Protokolle Sicherheit Authentifizierung Quality-of-Service und Profile
373 375 376 377 379 380
Management, Accounting, Logging und weitere Funktionen 382 384 385 389 389 389 390 391 392 393 394 395 398 399 399 400 404 405 406 409 409 411 413 Zum Unternehmen Das Projekt Projektablauf und Realisierung Zu den Unternehmen Das Projekt Projektablauf und Realisierung
11.4.10 VPN-Routing 11.5 Die Auswahl von VPN-Clientsoftware 12 Fallstudien 12.1 Studie 1: Die Software AG 12.1.1 12.1.2 12.1.3 12.2.1 12.2.2 12.2.3
12.2 Studie 2: Der Blutspendedienst des DRK
12.3 VPN-Dienste von Service Providern 12.4 Studie 3: Die VIAG Interkom 12.4.1 12.4.2 12.4.3 12.4.4 12.4.5 13 Anhang Weiterfhrende Literatur Links 14 Stichwortverzeichnis Zum Unternehmen Der IP-VPN-Dienst Infrastruktur Remote-Access-VPN Branch-to-Branch-VPN
Vorwort
Das Internet, einstmals nur Medium fr kryptische E-Mails und FTP-Dateitransfers mit einer berschaubaren Anzahl von Benutzern, hat sich von einer Gre von einigen wenigen 1,5-Mbit/s-Verbindungen (T1-Links) zu einem weltumspannenden, leistungsfhigen Netzwerk mit einer eigenen grafischen Oberflche entwickelt. Seine Verbindungsgeschwindigkeiten reichen mittlerweile bis in den Terabit-Bereich, was mehr als 660.000 parallelen T1-Links entspricht! Das Internet wird darber hinaus zunehmend zum Medium fr die Geschftsprozesse vieler Unternehmen, ja sogar ganze Firmen basieren bereits darauf. Kein Unternehmen kann es sich heute mehr leisten, nicht im World Wide Web prsent zu sein und bestimmte Prozesse wie Bestellungen, OnlineDienste oder einfach nur Produktinformationen nicht ber dieses Medium seinen Kunden zur Verfgung zu stellen. Die Anzahl der Internet-Zugnge wchst stndig, und damit steigt auch die Zahl der Personen und Organisationen immer weiter, die ber sie in Sekundenschnelle erreicht werden knnen. Somit entsteht natrlich zunehmend der Wunsch, dieses riesige weltweite Netzwerk und nichts anderes ist das Internet auch zum Zweck privater Kommunikation zu benutzen, indem man es verwendet, um verschiedene, mglicherweise international verteilte Standorte und Personen miteinander zu verbinden. Die Gre und die mittlere Geschwindigkeit des Internets machen dies mglich, und zwar zu Kosten, die weit unter dem liegen, was man heutzutage fr exklusive Verbindungen bezahlen muss. Allerdings ist die Datenkommunikation im Internet nicht vertraulich und integer, da das Internet-Protokoll (IP) keine Sicherheitsfunktionen dafr bereitstellt. Die private Datenkommunikation erfordert jedoch die Vertraulichkeit, Integritt und Authentizitt der bertragenen Informationen. Die Technik der virtuellen privaten Netzwerke ist die Lsung, um diese beiden divergierenden Forderungen gleichermaen erfllen zu knnen. Auf der Basis moderner und sicherer Protokolle wie IP Security (IPSec) knnen die Vorteile des Internets auch auf die private Datenkommunikation unter Wahrung der Vertraulichkeit und Integritt privater Informationen angewendet werden. Damit birgt diese Technologie fr Unternehmen jeder Grenordnung ein hohes Ratiopotenzial. Dieses Buch wendet sich sowohl an Leser, die sich allgemein fr die relativ neue Technologie sicherer Internet-VPNs interessieren, als auch an solche, die planen, eine VPN-Lsung zu implementieren und einzusetzen. Das Ziel dieses Buches ist es, Ihnen das ntige Wissen zur Planung, Realisierung und Administration von virtuellen privaten Netzwerken zu vermitteln. Besonderer Wert wurde dabei auf Herstellerneutralitt gelegt.
15
Vorwort
Aufbau
Dieses Buch ist in drei Teile gegliedert: eine Einfhrung in die Thematik, eine ausfhrliche technische Beschreibung der wichtigsten VPN-Schlsseltechnologien und schlielich in berlegungen und Tipps zur Implementierung. Im Anhang finden Sie ein Verzeichnis von weiterfhrender Literatur und interessanten Links, auf die in diesem Buch an verschiedenen Stellen verwiesen wird. Der erste Teil besteht aus den ersten drei Kapiteln. Kapitel 1 beschftigt sich mit der Frage, was ein VPN eigentlich ist, wie es sich gegen andere Netzwerktechnologien abgrenzt und welchen Nutzen der Anwender daraus ziehen kann. Auerdem werden dort aktuelle und zuknftige Entwicklungen sowie Marktanalysen beschrieben. Kapitel 2 hat die unterschiedlichen Typen von virtuellen privaten Netzen zum Thema: die Remote-Access-, Branch-Office-, Extranet- und Intranet-VPNs und die VPN-Dienste, die in zunehmendem Mae von verschiedenen Service Providern und Carriern angeboten werden. In Kapitel 3 werden schlielich die technischen und qualitativen Anforderungen erlutert, die heute von modernen Unternehmensnetzen an VPNs gestellt werden. Vitale Themen wie Datensicherheit, Verfgbarkeit und Quality-ofService sind hierbei die Schwerpunkte. Der zweite Teil des Buches beschreibt ausfhrlich die in modernen IP-VPNs eingesetzten Technologien. Er besteht aus den Kapiteln 4 bis 9. In Kapitel 4 wird auf das Thema Sicherheit und die Grundlagen der Kryptologie eingegangen. In diesem Kapitel wurde besonderes Augenmerk auf die in heutigen VPNs eingesetzten Sicherheitstechnologien gerichtet. Kapitel 5 befasst sich mit dem Thema Authentifizierung und stellt die verschiedenen Verfahren und Applikationen vor. Das Thema digitale Signaturen und Public Key Infrastructure (PKI) wurde ausfhrlich behandelt, wobei auch rechtliche Aspekte bercksichtigt werden. Die verschiedenen Tunneling-Modelle, die man in einem VPN einsetzen kann, sind das Thema von Kapitel 6. Hier werden auch die wichtigsten TunnelingProtokolle beschrieben und gegenbergestellt. Kapitel 7 befasst sich mit dem Thema IP Security (IPSec) und beschreibt detailliert die Funktionen dieser Protokollfamilie, die einen weit reichenden Schutz der IP-Kommunikation garantiert. In Kapitel 8 finden Sie eine Beschreibung des Internet-Key-Exchange-Protokolls (IKE). Da IKE fr eine sichere IPSec-Kommunikation sehr wichtig ist, ist das Kapitel recht ausfhrlich ausgefallen. Die verschiedenen Modi und Betriebsarten werden dort detailliert erlutert. Als wichtigster Vertreter seiner Familie wird in Kapitel 9 das Layer-2-Tunneling Protocol (L2TP) und sein Einsatz in Zusammenarbeit mit IPSec in modernen Betriebssystemen vorgestellt. Teil Drei umfasst Kapitel 10 bis 12 und ist der praktischen Umsetzung gewidmet. Kapitel 10 beschreibt die verschiedenen Phasen bei der Planung und Realisierung von VPNs von der Ist-Analyse bis zum Aufbau. Kapitel 11
16
Danksagung
beschftigt sich mit der Auswahl der VPN-Komponenten. Hier wird, statt der sonst blichen und schnell veralteten Hersteller- und Produktbersicht, detailliert auf die Kriterien zur Produkt- und Herstellerauswahl eingegangen und beispielhaft die Erstellung eines geeigneten Anforderungskatalogs beschrieben. Kapitel 12 gibt abschlieend anhand von Fallstudien verschiedener Unternehmen einen tiefen und informativen Einblick in bereits realisierte VPNs und VPN-Dienste.
Danksagung
Insbesondere meinem Vater, meiner Freundin Gaby und meinen ganzen Freunden und Bekannten mchte ich an dieser Stelle fr ihre Geduld und ihr Verstndnis dafr danken, dass ich in den letzten Wochen und Monaten nur sehr wenig Zeit fr sie erbrigen konnte. Da ich dieses Buch neben meiner eigentlichen Berufsttigkeit geschrieben habe, musste ich dafr sehr viele Abende und Wochenenden investieren. Mein weiterer Dank gilt der Firma Nortel Networks und dort insbesondere Andreas Herden, Martin Ruoff und Armin Schmidt fr ihre wohlwollende Untersttzung. Sehr viel von dem, was ich an praktischer Erfahrung in dieses Buch einbringen konnte, habe ich bei diesem Unternehmen in zahlreichen Projekten sammeln knnen. Besonderen Dank mchte ich auch dem Blutspendedienst des Deutschen Roten Kreuzes, den Firmen ASAP.COM, Software AG und VIAG Interkom aussprechen. Insbesondere gilt hier mein Dank den Herren Dieter Kaper, Gerd Mitschke, Christoph Pischka und Oliver Truetsch fr ihre wertvollen Informationen und Anregungen zu den Fallstudien in diesem Buch. Auch all den Teilnehmern der VPN-, WAN- und Security-Technology-Seminare der Nortel Networks Network Academy, die mich durch ihre Kritik, ihre Vorschlge und ihre vielen Anregungen zum Schreiben dieses Buches veranlasst haben und deren Namen ich hier verstndlicherweise nicht alle nennen kann, sei an dieser Stelle gedankt. Weiterhin mchte ich besonders meinen Lektoren, Frau Friederike Daenecke und Herrn Rolf Pakendorf, fr ihre Mhe und ihre tatkrftige Untersttzung bei der Entstehung dieses Buches danken. Fr die technische Untersttzung bei der Erstellung des Manuskripts mchte ich Herrn Karl Kienle danken. Stuttgart Manfred Lipp
17
1
1.1
Virtuelle private Netzwerke

Was ist ein VPN?
Was ist ein VPN? Ein VPN (virtuelles privates Netzwerk) ist ein Netzwerk, das ein ffentliches Netzwerk benutzt, um private Daten zu transportieren. Dies ist zugegebenermaen eine recht allgemein gehaltene Definition, die aber allen Arten von VPNs gerecht wird. In der heutigen Zeit wird ein VPN sehr oft nur auf die Benutzung des Internets als ffentliches Netzwerk reduziert, was aber so nicht stimmt. Wie Sie in diesem Kapitel sehen werden, gibt es eine ganze Reihe anderer, teilweise schon recht alter VPN-Technologien, die berhaupt keinen Gebrauch vom Internet machen. Auch spricht man in diesem Zusammenhang oft nur von Datenbertragung, aber es gibt auch reine Sprach-VPNs und in Zukunft auch so genannte Unified-VPNs, also Netze, die zur gleichzeitigen bertragung von Sprache, Daten und interaktiven Videokonferenzen geeignet sind. Diese Tendenz, fr die sich mittlerweile der Ausdruck Konvergenz oder auch Konvergenz der Netze als allgemein gltiger Begriff etabliert hat, fhrt zu einigen unverzichtbaren Anforderungen an solche Netzwerke. Denn im Gegensatz zur reinen Datenbertragung, bei der es in den meisten Fllen nicht so sehr darauf ankommt, ob die Pakte verzgert ankommen, und die auch mit zeitweise geringen Bandbreiten auskommt, mssen diese neuen, konvergierten Netze fr Datenstrme bestimmter Dienste gewisse Qualitten netzwerkweit garantieren knnen. Diese Forderung, die in lokalen Netzen und bestimmten Arten von ffentlichen Netzen durchaus realisierbar ist, wird in IP- beziehungsweise Internet-VPNs zu einem extrem kritischen Faktor, der in diesem Buch auch angemessen bercksichtigt ist. Aber zurck zur Definition eines virtuellen privaten Netzwerks. Das Gegenstck zum VPN ist ein echtes privates Netzwerk, also ein Netzwerk, das exklusiv von einem Unternehmen oder einer Organisation betrieben wird. Das heit, alle bertragungseinrichtungen und alle bertragungsmedien gehren diesem Unternehmen oder sind ihm zur exklusiven Nutzung berlassen. Beispiele sind die so genannten Mietleitungen oder Standardfestverbindungen, die einer Organisation zur ausschlielichen Nutzung vermietet werden. Mit geeignetem Equipment zur Daten- oder Sprachbertragung ber diese Leitungen wird ein scheinbar rein privates Netzwerk betrieben. Scheinbar deshalb, weil die Verbindungen zwar ausschlielich vom Mieter derselben benutzt werden, jedoch meist, zumindest in Europa, Teil einer ffentlichen Netzwerkinfrastruktur sind. Diese Infrastruktur bietet jedoch umfassende Mglichkei-
19
1 Virtuelle private Netzwerke
ten zum Anzapfen dieser Verbindung und stellt somit in jedem Fall ein mgliches Sicherheitsrisiko dar auch wenn die Betreiber solcher Netze natrlich keinen Missbrauch treiben drfen und ein Abhren nur aufgrund einer richterlichen Anordnung durch bestimmte Personen zulssig ist. Ein ffentliches Netzwerk hingegen ist eine Kommunikationsinfrastruktur, die von einem Dienstleistungsunternehmen betrieben wird, das die Benutzung des Netzes jedermann gegen ein entsprechendes Verbindungsentgelt ermglicht. Ein Beispiel hierfr sind ffentliche Telefonnetze. Jeder kann gegen eine entsprechende Gebhr dieses Netz benutzen. Ein VPN versucht, private und ffentliche Netzwerke zu kombinieren, indem das ffentliche Netzwerk als Trgernetzwerk fr die private Kommunikation benutzt wird.
1.2
Geschichte und Technologien
Virtuelle private Netzwerke gibt es schon seit einiger Zeit. Sie wurden aber nicht immer so genannt. In der Vergangenheit wurden vielfach andere Begriffe verwendet, z.B. Corporate Network. Ein ganze Reihe, teilweise schon recht lange im Einsatz befindlicher Technologien eignet sich als Basistechnologie fr VPNs: ISDN Frame Relay ATM Das Internet ISDN Eine schon etwas ltere VPN-Technologie sind zum Beispiel die so genannten geschlossenen Nummernkreise in einem digitalen Telefonnetzwerk wie dem ISDN (Integrated Services Digital Network, ein leitungsvermittelndes, digitales Multiservice-Netzwerk). Das Telekommunikationsunternehmen vergibt hierbei fr die Anschlsse eines Kunden eine Reihe von Telefonnummern, die nur untereinander kommunizieren knnen. Verbindungen zu oder von Nummern auerhalb dieses Nummernkreises sind nicht mglich. Aus Sicht des Unternehmens sieht dies wie ein privates, abgeschlossenes Telefonnetz aus. In Wirklichkeit wird aber das ffentliche Netzwerk des Telekommunikationsunternehmens benutzt, das die ntige Infrastruktur in Form von Leitungen und Vermittlungssystemen zur Verfgung stellt. Die Kommunikation zu Nummern auerhalb des geschlossenen Nummernkreises ist nur ber ein Schnittstellensystem, z.B. eine Nebenstellenanlage, mglich, die einen bergang zum ffentlichen Netzwerk bietet.
20
Frame Relay Eine andere, ebenfalls bereits lnger verfgbare VPN-Variante sind Netzwerke, die auf dem Frame-Relay-Verfahren basieren. Frame Relay ist eine bertragungstechnologie, die ursprnglich zum reinen Datentransport entwickelt wurde, aber auch zunehmend fr gemischte Sprach- und Datenbertragung verwendet wird. Der Frame-Relay- Standard wurde eigentlich auf Grundlage des X.25-Standards als ISDN-Datenbertragungsprotokoll entwickelt. Das Frame Relay Forum, das 1991 gegrndet wurde, definiert die notwendigen, herstellerbergreifenden Standards hierfr. Obwohl es aus dem X.25-Standard hervorgegangen ist, existieren zu diesem doch wesentliche Unterschiede. So arbeitet Frame Relay mit viel hheren Geschwindigkeiten, mit teilweise bis zu 45 Mbit/s. Da Frame Relay eine hohe Leitungsqualitt voraussetzt, wurden auch nicht so aufwendige und ressourcenintensive Mechanismen zu Sicherung der bertragung bentigt, wie dies beim X.25-Protokoll der Fall ist.
Netzwerk A
Router A
Netzwerk B
Netzwerk C
PVC 1
Router B
PVC 2
Router C
PVC 3 PVC 4
PVC 5
PVC 6
Router D
Frame-RelayNetzwerk
Netzwerk D
Abbildung 1.1: Im Frame-Relay-VPN werden die permanenten virtuellen Verbindungen auf der OSI-Schicht 2 abgebildet.
Frame Relay ist aus der Sicht des Anwenders ein verbindungsorientiertes Protokoll. Das heit, es muss eine so genannte virtuelle Verbindung zwischen zwei Datenbertragungseinrichtungen existieren. Diese kann entweder vom Provider fest konfiguriert und dauerhaft aktiviert werden oder erst bei anstehender Datenbertragung vom Kunden aktiviert und anschlieend wieder deaktiviert werden. Die erste Variante nennt man PVC (Permanent Virtual Circuit), und die zweite Variante wird als SVC (Switched Virtual Circuit) bezeichnet. Die Pfade werden deshalb als virtuell bezeichnet, weil in Wirk-
21
lichkeit keine physikalische Ende-zu-Ende-Verbindung besteht. Tatschlich ist der Weg der Frames durch ein Frame-Relay-Netzwerk dynamisch; bei Ausfllen oder berlasten knnen alternative Routen gewhlt werden. Fr den Abonnenten eines Frame-Relay-PVCs ist dies alles nicht sichtbar, fr ihn stellt sich das Ganze als Punkt-zu-Punkt-Verbindung dar. Neben der hohen Geschwindigkeit bietet Frame Relay aber einiges mehr; insbesondere knnen verschiedene Dienstqualitten zwischen Provider und Kunde vereinbart werden. So knnen Parameter wie garantierte Bandbreite und maximale Bandbreite vereinbart werden. Es ist auch mglich, in einer Verbindung zu einem Frame-Relay-Netz-Zugangsknoten gleichzeitig mehrere PVCs mit verschiedenen Parametern fr verschieden priorisierte Dienste wie SAP, Sprache und unkritischen Datenverkehr zu konfigurieren. Auch in Hinblick auf seine groe Verbreitung (es wird praktisch weltweit angeboten) eignet sich Frame Relay vom technischen Standpunkt aus gesehen hervorragend als Basis zum Aufbau von VPNs. Fr detaillierte Informationen zu Frame Relay sei auf die einschlgige Fachliteratur verwiesen. Der Asynchronous Transfer Mode, ATM Neben Frame Relay hat sich auch ATM (Asynchronous Transfer Mode) als Basis fr die Art von ffentlichen Netzwerken etabliert, die sich sehr gut zum Aufbau von VPNs eignen. Beim Stichwort ATM fallen Ihnen zuerst wahrscheinlich zwei Begriffe ein: Geschwindigkeit und Komplexitt.
Daten Sprache Video Leerzellen bertragung mit maximaler Bitrate
Daten Sprache Video
Segmentierung
Reassemblierung
Abbildung 1.2: ATM ermglicht die bertragung der verschiedensten Arten von Datenverkehr.
Die ATM-Technologie als solche ist, sobald man sich ein wenig mit ihr beschftigt hat, gar nicht so komplex. Allerdings steigt die Komplexitt mit der Komplexitt des Einsatzes dieser Technologie, insbesondere dann, wenn sie zu Dingen benutzt wird, fr die sie nicht ausgelegt wurde, beispielsweise fr die Emulation von Ethernet- oder Token-Ring-Netzwerken. Wenn mit einem verbindungsorientierten Netzwerk wie ATM ein auf Broadcasts basierendes Netzwerk wie Ethernet emuliert werden soll, dann wird es eben kompliziert.
22
In einem ATM-Netzwerk kann man sehr schnell Daten bertragen, aber das ist gar nicht einmal das wichtigste Kriterium fr seine Auswahl, sondern es geht um die damit mglichen abgestuften Dienstqualitten und die gute Eignung zur bertragung von isochronen Datenstrmen wie Sprache oder Video. Im Gegensatz zum Frame-Relay-Verfahren, mit dem Daten von mehreren tausend Byte in einem Frame bertragen werden knnen, benutzt man bei ATM das Cell Switching. Es werden dabei sehr kleine Zellen bertragen, die eine feste Lnge von 53 Byte haben. Die Nutzdatenpakete werden vor der bertragung in 48 Byte groe Zellen aufgeteilt, mit einem Header versehen und in den 53 Byte groen ATM-Zellen synchron bertragen. Auf der Empfngerseite werden die Pakete wieder zusammengesetzt, sofern keine Zellen aufgrund von berlastsituationen verworfen wurden. Denn ATM, ebenso wie Frame Relay, erlaubt es, Zellen zu verwerfen, sofern sie entsprechend gekennzeichnet sind und einer entsprechenden Dienstklasse angehren. Bei Sprachoder Videobertragungen ist dies meist kein Problem, denn durch die minimale Gre der ATM-Zellen bleibt die akustische oder optische Strung in der Regel subjektiv unbemerkt. Auch bei den meisten Datenbertragungen ist dieses Verhalten akzeptabel, denn die hheren bertragungsprotokolle fordern das gesamte Paket einfach noch einmal an.
PC
Netzwerk A Gateway A
Tunnel
Netzwerk C
Internet
Tunnel
Tunnel
Tunnel
Gateway C
Gateway B
Netzwerk B
Abbildung 1.3: Im Internet-VPN werden die virtuellen Verbindungen auf der OSI-Schicht 3, der Netzwerkschicht, abgebildet.
Wer sich tiefer in dieses Thema einlesen mchte, dem sei auch an dieser Stelle die umfangreiche weiterfhrende Literatur empfohlen.
23
Das Internet In neuerer Zeit spricht man immer fter von IP-VPNs oder auch InternetVPNs. Der fundamentale Unterschied zu virtuellen privaten Netzwerken auf Basis von ISDN, Frame Relay oder ATM ist der, dass die Trgertechnologie nicht auf der Ebene 2 des OSI-Schichtenmodells, sondern auf der Ebene 3, der Netzwerkschicht, liegt. Der groe Vorteil liegt darin, dass man damit von physikalischen Infrastrukturen unabhngig wird. Das IP-VPN transportiert IP-Pakete zwischen zwei Endsystemen. Ob das IP-Paket whrend der bertragung in ATM, Frame Relay (oder was auch immer und in welcher Kombination auch immer) eingekapselt wird, ist aus Sicht des VPN unerheblich. Ein Internet-VPN benutzt das Internet, das weltgrte und immer noch stark wachsende IP-Netzwerk, als ffentliches Netzwerk.
1.3
Warum VPNs?
Der Hauptgrund fr den Einsatz virtueller privater Netzwerke besteht in deren niedrigen Betriebskosten. Dies gilt insbesondere fr Internet-VPNs; bei VPNs auf Basis von ATM und Frame Relay sind die Einsparungen lngst nicht so hoch. Nicht selten sind die Gesamtkosten eines Internet-VPNs, also die Summe aus Investitionen und den Betriebskosten, schon fr das erste halbe Jahr geringer als unter Verwendung von traditionellen Netzwerkkomponenten! Somit gibt der Kostenfaktor meist den Hauptausschlag zugunsten dieser neuen Technologie. Der Spitzname fr VPNs Very Profitable Network kommt nicht von ungefhr.
Einwhl-RemoteAccess Monatliche Grundgebhr (2 x E1) Volumengebhr (7,6 Gbyte) Zeitgebhr Dial-In (0,05 DM/min) Zeitgebhr VPN (79,- DM/Monat Flatrate) Summe DM 48.644,DM 47.520,DM 4.740 DM 9.796,DM 1.124,VPN-RemoteAccess DM 4.264,DM 792,-
Tab. 1.1: Ein Kostenvergleich zwischen Remote Access auf Basis von Einwhl- und VPN-Technologie
In Tabelle 1.1 sehen Sie eine Beispielrechnung dafr, wie hoch die Einsparungen beim Einsatz eines Remote-Access-VPN sein knnen. Als Beispiel wurde ein Netzwerk eines mittelstndischen Unternehmens gewhlt, das maximal 60 gleichzeitige Verbindungen in das Unternehmensnetzwerk zur Verfgung stellen will. Es wurde sehr konservativ gerechnet und der am 11. Dezember
24
Warum VPNs?
2000 billigste Anbieter mit 5 Pf/min (in der Fernzone) genommen. Die bertragene Datenmenge von 7,6 Gbyte berechnet sich unter der Annahme, dass alle 60 B-Kanle des Remote-Access-Systems zwlf Stunden am Tag und 22 Tage im Monat (dies entspricht einer Verbindungszeit von 950.400 Minuten pro Monat) mit voller Bandbreite ausgelastet sind. Die Alternative dazu, der Einsatz von VPN-Technologie, legt zwei E1-Verbindungen (2 Mbit/s) mit einem monatlichen Datenvolumen von 7,6 Gbyte zu einem ISP zugrunde. Die Einwahl der Benutzer erfolgt bei einem Provider mit einer so genannten Flatrate von DM 79,- pro Monat inklusive Telefongebhren. Die Betriebskosten der beiden Lsungen wurden in beiden Fllen als gleichwertig angenommen. Die Anschaffungskosten der Hardware unterscheiden sich ebenfalls: Ein dem notwendigen Remote-Access-Konzentrator gleichwertiges VPN-System kostet im Schnitt etwa 50% weniger, bei hohen Portdichten sogar bis zu 80% weniger! Das Einspar-Potenzial liegt bei 38.788 DM pro Monat, also bei einer Tarifersparnis von fast 80% das ergibt eine jhrliche Einsparung von 465.465 DM. Und dies ist noch eine vergleichsweise kleine Remote-Access-Lsung. Ich erwhnte bereits, dass dieses Beispiel extrem konservativ gerechnet ist. Denn in der Praxis wird meist etwas schrfer kalkuliert: Es ist nmlich sehr unrealistisch, dass alle 60 B-Kanle der Remote-Access-Lsung zwlf Stunden am Tag mit voller Bandbreite betrieben werden, wodurch sich die zugrunde gelegte Gesamtbandbreite von 4 Mbit ergeben wrde. Es ist vielmehr so, dass eine Verkehrsanalyse in den meisten Fllen ergeben wird, dass die Gesamtbandbreite statistisch gesehen fast immer deutlich darunter liegt. Und nur diese Bandbreite msste ein VPN-Remote-Access-Konzentrator zur Verfgung stellen, wodurch die Zugangsverbindung zum Internet deutlich schmalbandiger und damit kostengnstiger ausfallen kann. Hier kommt der Vorteil eines IP-VPNs, nmlich ber ein paketorientiertes Netzwerk ein leitungsvermittelndes Netz zu simulieren, voll zum Tragen. Die Grnde fr den Einsatz von virtuellen privaten Netzen sind recht vielfltig und vom Geschftsmodell der Betreiber abhngig. In Abbildung 1.7 sehen Sie die Resultate einer Umfrage, die ermitteln sollte, zu welchem Zweck die befragten Unternehmen die VPN-Technologie einsetzen. Nach wie vor nimmt der Remote Access eine fhrende Stellung ein, wohl deshalb, weil damit am schnellsten sehr hohe Einsparungen zu erzielen sind. Zum anderen bieten Internet-VPNs hufig eine groe Flexibilitt: Man kann sehr schnell neue Benutzer und Standorte in sein Netzwerk einbinden. Ein neuer Remote-Access-Benutzer braucht sich zum Beispiel nur beim Service Provider anzumelden und kann gleich danach das VPN benutzen. Es mssen keine Gerte beschafft oder erweitert und keine neuen Zugangsleitungen bestellt werden.
25
Warum hat sich dann nicht jeder schon vor Jahren auf Internet-VPNs gestrzt? Das Problem liegt im Internet begrndet, denn eine wichtige Sache bietet das Internet noch nicht: garantierbare Bandbreiten und Verzgerungszeiten. Auch vom Standpunkt der Sicherheit aus gibt es heute oft noch erhebliche Bedenken, das Internet zum Transport privater Daten zu benutzen. Eine ganze Reihe dieser Einwnde lsst sich aber durch heute frei verfgbare Technologien zur Datenverschlsselung und generellen Netzwerksicherheit zerstreuen, einzig das Problem der nicht garantierten Dienstqualitt bleibt vorerst noch bestehen. Aber auch daran wird gearbeitet, und es gibt mittlerweile auch schon brauchbare Lsungen sie mssen nur noch implementiert werden.
1.4
Rahmenbedingungen fr den Einsatz
Der sinnvolle und mgliche Einsatz eines VPNs hngt von verschiedenen Rahmenbedingungen ab, die von Land zu Land und von Benutzer zu Benutzer unterschiedlich sein knnen.
Challengers Leaders
Cisco Check Point
Nortel Networks
Execute
Lucent IBM Axent IRE
3Com
NAI Intel/Shiva
Ability
TimeStep Watchguard Secure Computing Compatible Systems VPNet Radguard Red Creek Indus River Altiga
InfoExpress
Niche Players
Visionaries
Completeness of Vision
Abbildung 1.4: Eine Analyse des Remote-Access-VPN-Marktes (Quelle: Gartner Group, 1999)
26
Rahmenbedingungen fr den Einsatz
Eine der Hauptmotivationen, der Kostenaspekt, ist sehr variabel, sowohl zeitlich als auch regional. In den meisten Lndern gibt es sehr unterschiedliche Tarife, sowohl im Bereich der ffentlichen Netze als auch fr den Internetzugang. Da VPNs oft international ausgelegt werden, muss man mit den unterschiedlichsten Tarifen und Zugangstechnologien kalkulieren, was schnell etwas unbersichtlich werden kann. Ein Beispiel: In den USA oder Kanada bekommt man schnell und sehr kostengnstig DSL-Anschlsse. In Deutschland bekommt man nach wie vor, auer in den Ballungszentren, meist nur ein bedauerndes Kopfschtteln zu sehen und einen Platz auf der Warteliste zugewiesen. Und wenn es so weit ist, schlagen, im Gegensatz zu Nordamerika, erheblich hhere Kosten zu Buche. Je weiter ein VPN international gespannt wird, desto komplexer werden die Kostenkalkulationen, die auch stndigen nderungen durch glcklicherweise meist fallende Gebhren unterworfen sind. Weiterhin gibt es auch die unterschiedlichsten Zugangstechnologien, die sowohl von der Technik als auch von den Kosten regional wieder sehr unterschiedlich sein knnen. Hinzu kommt, dass nicht alle Provider immer alles anbieten, was technisch mglich wre. Whrend in Deutschland ISDN sehr verbreitet ist, kennt in den USA diese Technik im Heimbereich praktisch niemand, sie wird noch nicht einmal angeboten, auer in ganz wenigen Fllen. Weitere Rahmenbedingungen sind rechtlicher Natur. Bei Internet-VPNs finden in der Regel bestimmte Verschlsselungstechnologien Anwendung. In bestimmten Regionen unserer Erde darf man solche Produkte aber berhaupt nicht einsetzen; in anderen Lndern sind nur Produkte mit so genannter schwacher Verschlsselung erlaubt. Wiederum andere Lnder beschrnken den Export solcher Systeme. In Deutschland fllt die Ausfuhr starker Verschlsselungssysteme beispielsweise unter das Kriegswaffen-Kontrollgesetz.
12.000 10.000
IP-VPN (US) IP-VPN (Rest) IP-VPN (Global)

2.000
1998
1999
2000
2001
2002
2003
Total global IP-VPN service revenue $US m
Abbildung 1.5: Eine Prognose zur weltweiten Marktentwicklung von IP-VPNs
27
Auch die Zukunft von VPNs, die auch Sprache bertragen knnen, ist noch nicht geklrt! Die heutige ffentliche Sprachkommunikation darf nach einer richterlichen Genehmigung von den Strafverfolgungsbehrden abgehrt werden das ist in allen Lndern gang und gbe. Die Telekommunikationsunternehmen stellen die dafr notwendigen Schnittstellen zur Verfgung. Was wird aber, wenn Sprachdaten zunehmend ber Internet-VPNs bertragen werden, und die IP-Pakete durch den Einsatz von starker Verschlsselung vor jedem Abhren geschtzt sind? Wie lange bleibt der Gesetzgeber dabei unttig?
1.5
Der VPN-Markt
Der VPN-Markt ist augenblicklich ein sehr dynamischer Markt. In den USA begann vor etwa drei Jahren ein regelrechter Boom im Bereich der InternetVPNs. Dort schoss eine Reihe kleiner Startup-Unternehmen aus dem Boden, die sich auf reine IP-VPN-Technologie konzentrierten und die erste reine VPN-Hard- und -Software entwickelten. Auch die Groen der Netzwerkbranche reagierten, wie heutzutage blich, durch die bernahme einiger dieser Firmen und die Integration von deren Produkten in das eigene Produktportfolio. Dies erschwert leider auch die Auswahl eines Herstellers, da die Zukunft etlicher Firmen und ihrer Produkte nur sehr schwer vorherzusagen ist. Dieses Problem wird noch dadurch verschrft, dass ausgerechnet die kleinen Unternehmen oft die interessantesten und besten Produkte haben. Nicht selten wurden solche Unternehmen von Mitarbeitern groer Firmen gegrndet, die ihre Ideen an ihrem alten Arbeitsplatz nicht verwirklichen konnten. Aus Frustration ber die meist unvermeidliche Brokratie und die langen, manchmal schwer nachvollziehbaren Entscheidungswege in Grounternehmen verlieen sie ihre Arbeitgeber und grndeten mit anderen Leidensgenossen eine eigene Firma. Geldgeber, die ausreichend Kapital in solche Unternehmen stecken, finden sich in den USA recht problemlos, und die rechtlichen Rahmenbedingungen sind dort ebenfalls innovationsfreundlicher als zum Beispiel in Deutschland. In solchen kleinen Firmen, in der Atmosphre eines High-Tech-Startups und mit der hohen Motivation ihrer Mitarbeiter, die alle an ihre Ideen glauben, wurden in den letzten Jahren die wichtigsten Technologien und Systeme im Bereich der IP-VPNs entwickelt. Auch in Deutschland begann sich im Jahre 1999 der Internet-VPN-Markt sehr positiv zu entwickeln. Aufgrund des rasanten Wachstums des Internets und des wachsenden Bedarfs von Unternehmen an internationaler, breitbandiger Weitverkehrskommunikation sagen die Analysten sogar ein noch viel strkeres Marktwachstum voraus. Wie fast alle Entwicklungen, die hauptschlich in den USA entstanden, war auch diese Technologie erst ein bis zwei Jahre spter nach Deutschland gekommen. Dies hing mit einer ganzen Reihe von ungnstigen Faktoren zusammen,
28
Der VPN-Markt
vor allem mit der spten Liberalisierung des Telekommunikationsmarktes, einer gewissen Abwartehaltung der potenziellen Anwender und der rgerlichen Tendenz einiger Carrier und Service Provider, ihre herkmmlichen WAN-Systeme und Dienstleistungen, in die sie einiges fr Entwicklung und Anschaffung investiert hatten, erst einmal weiter zu vermarkten und das Thema VPN am besten gar nicht zu erwhnen. Die Fachliteratur hatte sich auch weitgehend zu dem Thema ausgeschwiegen, und auch in Fachpresse wurde dem Thema lange Zeit eher eine Nischenposition zugewiesen. Selbst die Hersteller hatten es nicht eilig, sich mit dieser Technologie zu befassen, da sie mit traditionellen Routern und Remote-Access-Konzentratoren einen um ein Vielfaches hheren Umsatz machen konnten als mit der vergleichbaren VPN-Technologie. Denn vom so genannten Straenpreis ausgehend, musste ein Kunde fr ein Remote-Access-System mit 1.000 gleichzeitigen analogen oder digitalen Einwhlverbindungen etwa 450.000 DM in seine Hardware investieren, im Fall eines VPN-Konzentrators nur etwa 40.000 DM. So fehlte denn aufgrund fehlender Informationen auch lange Zeit der Druck vom Kunden, und das Thema wurde bei uns zu einem Sptstarter. Aber frei nach dem Motto Lieber spt als nie boomt der Markt mittlerweile auch in Deutschland, insbesondere im Bereich der Internet-VPNs.
8.000 7.000
Umsatz in Millio nen Dolla r
6.000 5.000 4.000 3.000 2.000 1.000 0 1998 1999 Fram e Relay IP-VPN 2000 2001 2002 2003 2004 2005
Abbildung 1.6: Ein Vergleich zwischen der prognostizierten Entwicklung von Frame-Relayund IP-VPNs (Quelle: The Yankee Group, 2000)
29
Die zuknftige Marktentwicklung fr virtuelle private Netze wird von den Analysten durchweg als sehr positiv bewertet. Die Yankee Group prognostiziert ein Umsatzwachstum in diesem Markt von 260 Millionen US-Dollar (USD) im Jahr 1999 auf 6,8 Milliarden USD im Jahr 2005. Insgesamt wird der Trend beobachtet, dass immer mehr Unternehmen neue Investitionen eher in die VPN-Technologie als in traditionelle WAN-Lsungen ttigen. Die Gartner Group prognostiziert (in der Network World, 13. Januar 2000) ein Wachstum des Gesamtmarktes von heute 145 Milliarden auf ber 7 Billionen US-Dollar im Jahr 2001. Hierin sind alle Umstze, also Hardware, Software, Tarife und Dienstleistungen im Endkunden- und Service-Provider-Bereich, eingerechnet. Hinzu kommt, dass die Carrier und Service Provider IP-VPNs als Komplettlsung in ihr Angebotsportfolio aufgenommen haben und in diesem Bereich eine Reihe unterschiedlicher Lsungen offerieren. Diese reichen vom einfachen Internet-Zugriff bis hin zu Komplettlsungen inklusive Netzwerkmanagement. Es wird wohl in Zukunft immer mehr so aussehen, dass sich der Netzwerkplaner nicht mehr fragt, ob er die VPN-Technologie einsetzen soll, sondern wie.
1.6
IP-VPNs und das Internet
Auslser fr diese Entwicklung gibt es gleich mehrere. Nachdem sich das Internet endgltig von dem Begriff free im Sinne von umsonst verabschiedet hat und nachdem es aus dem universitren Bereich herausgelst wurde und sich die Groen der Telekommunikation seiner angenommen haben, wird es in einem Mae ausgebaut, wie es vor einigen Jahren niemand vorausgesagt htte Diese Entwicklung findet gleichzeitig in mehreren Bereichen statt: Die Zahl der so genannten Internetanschlsse und damit gleichbedeutend die Zahl der Endgerte nimmt rasant zu. Es ist zwar noch lange nicht so, dass jeder Rechner auf der Welt einen Internetanschluss hat, aber bedingt durch stndig sinkende Kosten und den steigenden Mehrwert des Netzes nimmt ihre Zahl deutlich zu. Die Bandbreite des Internets wird der in Zukunft notwendigen Kapazitt angepasst. Im Augenblick gibt es sogar ein regelrechtes Bandbreiten-berangebot, vor allem im Backbone-Bereich. Man darf sich hier durch das manchmal langsame World Wide Web nicht tuschen lassen. Dessen mitunter etwas drftige Performance beruht meist auf vllig unterdimensionierten Serverfarmen ohne vernnftige Lastverteilung und auf einer zu schmalbandigen Anbindung an den Internet-Backbone. Mit der Netzgeschwindigkeit selbst hat dies meist nichts zu tun, aber nur diese interessiert bei der Planung eines Internet-VPNs. Die Verfgbarkeit des Internets fr den Endkunden wird deutlich hher. Dies liegt hauptschlich daran, dass die Service Provider zunehmend durch so genannte SLAs (Service Level Agreement, eine Vereinbarung
30
IP-VPNs und das Internet
zwischen Service Provider und Endkunde ber Dienstqualitten wie Bandbreite und Verfgbarkeit) gezwungen werden, fr den Betrieb ihrer Datennetze hnliche Verfgbarkeitskriterien wie im Sprachvermittlungsbereich anzulegen. Hinzu kommen aktuelle Entwicklungen im Bereich CoS (Class-of-Service, Abstufung verschiedener Dienstqualitten hinsichtlich Bandbreite, Verzgerung und Verfgbarkeit), mit denen die Service Provider die Schwche des IPProtokolls in diesem Bereich kompensieren sollen. Dies alles deutet darauf hin, dass das zuknftige Internet ein weltweit verfgbares IP-Netzwerk mit einer hohen, skalierbaren Bandbreite, in Grenzen deterministischen Verzgerungszeiten, einer hohen Verfgbarkeit und einer Vielzahl unterschiedlicher Zugangstechnologien sein wird.
Intranet Remote Access Extranet Access E-Commerce Anderes
2%
0% 10% 20% 30% 40%
30% 34% 20% 14%
Abbildung 1.7: Der Remote Access steht nach wie vor an der Spitze der beliebtesten VPN-Anwendungen. (Quelle: Telechoice, 1999)
Obwohl sich das alles auf den ersten Blick sehr positiv anhrt, muss man, zumindest heute und in nherer Zukunft, noch einige Einschrnkungen machen. Dies hngt mit der Struktur und der augenblicklich eingesetzten Technologie des Internets zusammen. Das Internet basiert auf dem IP-Protokollstandard und den ganzen anderen damit zusammenhngenden RFCs (Request for Comment, Standards im Internetbereich), die teilweise schon einige Jahre auf dem Buckel haben und unter anderen technischen, gesellschaftlichen und kommerziellen Rahmenbedingungen entwickelt wurden, als heute vorliegen. Wie Sie wahrscheinlich wissen, liegt der Ursprung des IP-Protokolls im militrischen Bereich. Die ARPA (Advanced Research Projects Agency, eine Abteilung des US-Verteidigungsministeriums) entwickelte bereits 1969 ein Netzwerkprotokoll, das Datenpakete zwischen rumlich weit verteilten Rechnern sicher und schnell, auch bei Zerstrung einzelner bertragungsknoten, transportieren sollte. Das Ergebnis war das TCP/IP-Protokoll. Mit diesem Protokoll wurden dann in den USA auch Behrden- und Wissenschaftsnetze aufgebaut, und es fand seinen Weg in eine breite ffentlichkeit vor allem ber den univer-
31
sitren Bereich. Obwohl es als Weitverkehrsprotokoll konzipiert wurde, war es auch im LAN-Bereich einsetzbar und wurde in Betriebssysteme wie Unix, Windows und schlielich auch Novell integriert. Aber heutige Applikationen bentigen nicht selten Features, die die IP-Protokolle in ihrer jetzigen Form noch nicht bieten oder die noch nicht flchendeckend im Internet eingesetzt werden. So ist es zum Beispiel heute technisch noch nicht mglich, im Internet eine bestimmte Bandbreite oder Verzgerungszeit zu garantieren. Obwohl dies einige Service Provider in ihren SLAs tun, besitzen sie berhaupt noch nicht die technischen Mglichkeiten dazu, sie hoffen meist einfach, dass es schon klappen wird oder dass man sie nicht erwischt. Auerdem ist die Verfgbarkeit des Internets immer noch ein uerst kritischer Punkt, da etliche kleinere und mittlere Vermittlungsknoten immer noch mit Routern betrieben werden, die ursprnglich fr den Einsatz in Unternehmensnetzen entwickelt wurden und deren Ausfallsicherheit nicht den im Carrier-Umfeld blichen Mastben entspricht. Wenn man sich die Struktur des Internets einmal anschaut, kann man es grundstzlich in drei unterschiedliche Bereiche gliedern, die vom Backbonebis zum Access-Bereich abgestuft sind (siehe Abbildung 1.8). Im AccessBereich sind IP-Endgerte zu finden, also Endgerte wie PCs, Unix-Workstations, VPN-Gateways und Access-Router. Der Internet-Backbone dient ausschlielich dazu, mehrere Netze miteinander zu verbinden.
Nationaler ISP
NAP
Nationaler ISP
NAP
Nationaler ISP
Regionaler ISP
Regionaler ISP
Regionaler ISP
Enduser
Lokaler ISP
Lokaler ISP
Lokaler ISP
Lokaler ISP
Enduser
Enduser
Enduser
Enduser
Enduser
Enduser
NAP: Network Access Point Zustzlich mgliche Verbindungen
Abbildung 1.8: Die Struktur des Internets und die verschiedenen Arten von Internet Service Providern
32
Entwicklungen und Ausblicke
Aufgrund dieser Unterscheidung gibt es auch drei Klassen von ISPs (Internet Service Provider, eine Organisation, die Dienste wie den Zugriff auf das Internet, E-Mail usw. zur Verfgung stellt), und zwar solche, die nur einen Teil des Backbone betreiben, solche, die nur die Access-Technologie bereitstellen, und solche, die beides machen, ber deren Infrastruktur sowohl ein Teil des Internet-Backbone-Verkehrs transportiert wird als auch Zugriffsdienste fr Endanwender bereitgestellt werden.
1.7
Nach alldem sieht die Zukunft von virtuellen privaten Netzwerken sehr rosig aus. Die wichtigsten Rahmenbedingungen stimmen, die Technologie ist verfgbar, ebenso eine Auswahl der verschiedensten ffentlichen Netze, und die potenziellen Kunden haben die Idee der VPNs angenommen. Nun stellt sich die Frage, welche Art von VPN man einsetzen soll. Was ist am besten geeignet? Was ist zukunftssicher? Was ist am kostengnstigsten? Diese Fragen lassen sich einfach beantworten, denn es gibt praktisch keine Alternative mehr zu einem IP-VPN. Das Internet-Protokoll, so alt es auch sein mag, ist das Netzwerkprotokoll der Zukunft. Es wird alle anderen, noch brig gebliebenen Netzwerkprotokolle verdrngen. Man muss sich nur einmal die aktuellen Projekte der IETF (Internet Engineering Task Force, dem Gremium zur Entwicklung und Verabschiedung von Internet-Standards) anschauen, dann wei man, wohin der Internet-Zug fhrt. Es wird in Zukunft mglich sein, ber das Internet unternehmenskritische Applikationen zu betreiben, Geschfte abzuwickeln, vertrauliche Informationen zu bertragen und auch zu telefonieren. Wer jetzt sein VPN aufbaut und gewisse Anforderungen hat, die augenblicklich nur ber ATM oder Frame Relay zu erfllen sind, hat trotzdem noch alle Optionen. Denn der Einsatz solcher Netze verbietet nicht den Einsatz von IP als Netzwerkprotokoll. Wenn man sein Netzwerk-Design dementsprechend gestaltet, ist eine sptere Migration kein groer Aufwand mehr und zieht vor allem keinen Bruch in der privaten Netzwerkstruktur nach sich. Die zuknftige Entwicklung im Internet wird vor allem im Bereich der Erhhung der Bandbreite und der Verfgbarkeit sowie der durchgehenden Implementierung von Bandbreitenmanagement und verschiedenen Dienstqualitten stattfinden. Die Geschwindigkeiten, die man in Zukunft bentigt, werden mit optischen bertragungstechnologien erzielt werden. Neueste Entwicklungen wie DWDM (Dense Wave Division Multiplexing, die gleichzeitige bertragung von mehreren Lichtfarben ber eine Glasfaser) vervielfachen die bertragungskapazitten von existierenden Glasfaserverbindungen. Aufholverstrker, die bisher elektro-
33
nisch arbeiteten, also Licht in Elektrizitt umwandelten, diese verstrkten und die Elektrizitt wieder in Licht umwandelten, werden durch rein optische Verstrker ersetzt, die mit extrem hohen Bandbreiten und minimalster Verzgerung arbeiten. Router dringen in die Dimension von mehreren Tbit/s (1 Terabit = 1.000.000.000.000 Bit) vor; die allerneuesten Entwicklungen gehen in Richtung optischer Router. Hierbei werden die Lichtsignale nicht mehr in Elektrizitt umgewandelt und mit herkmmlicher elektronischer Routertechnologie verarbeitet, sondern ber mikroskopisch kleine Spiegel (MEM, Micro Electronic Mirror) blitzschnell in den richtigen optischen Pfad weitergeleitet. Mittlerweile laufen Untersuchungen und Entwicklungen, auch verschiedene Dienstklassen oder virtuelle Pfade auf bestimmte Lichtfarben abzubilden und auf diese Weise in ganz neue Dimensionen vorzustoen. Im Zuge dieser Entwicklungen wird auch die Paketverzgerung im Internet immer geringer. Diese hngt von der Anzahl der verschiedenen Netzknoten und von deren jeweiliger Verarbeitungsgeschwindigkeit ab. Je schneller diese Knoten sind und je weniger Knoten insgesamt durchlaufen werden, desto besser wird dieser Wert. Vor allem die neuen rein optischen Verstrker eliminieren die Verzgerungen, die durch die zweifache Medienkonvertierung in herkmmlichen opto-elektronischen Systemen nicht vermeidbar sind. An der Verfgbarkeit des Internets wird ebenfalls fleiig gearbeitet. Da zunehmend Hersteller am weiteren Auf- und Ausbau beteiligt sind, die teilweise schon seit ber hundert Jahren im Telefongeschft ttig sind und deren Hauptkriterium daher schon immer Ausfallsicherheit war, sind auch hier positive Entwicklungen festzustellen. Dass das Internet insgesamt einmal eine Verfgbarkeit von 99,999% haben wird, ist natrlich noch Zukunftsmusik. Dies liegt daran, dass es genau genommen das Internet nicht gibt. Es ist vielmehr ein Zusammenschluss von vielen Zugangs- und Backbone-Netzen verschiedenster Betreiber, in denen die unterschiedlichsten Technologien eingesetzt werden. Aber zumindest im Backbone-Bereich und zunehmend auch im AccessBereich ist die Verfgbarkeit des Netzes ein Thema geworden, das die Kunden auch in den Vertrgen mit den Providern festlegen wollen. Auch im Access-Bereich sind die Weichen auf Geschwindigkeit gestellt. Die 64 Kbit/s eines ISDN-B-Kanals reichen den meisten Anwendern und Anwendungen oft schon nicht mehr aus. Neue, schnellere Zugriffstechniken wie die drahtgebundene DSL-Technologie oder neue drahtlose Verfahren bieten Bandbreiten von mehreren hundert Kbit/s bis zu einigen Mbit/s. Glcklicherweise ist der Kostenverlauf der Tarife umgekehrt proportional zu den angebotenen Geschwindigkeiten, so dass auch im Bereich der Heimbros oder kleinen Niederlassungen zu niedrigen Kosten ein Vielfaches der bisherigen Bandbreiten zur Verfgung steht. Laut einer Studie von Forrester Research vom Mai 2000 wird erwartet, dass, trotz des momentan extrem schleppenden Anlaufs in Deutschland, im Jahr 2005 etwa jeder vierte Haushalt, also etwas ber neun Millionen Haushalte, in Deutschland ber einen Breitbandanschluss verfgt (siehe Abbildung 1.9).
34
10.000 9.000 8.000
Angaben in Tausend
7.000 6.000 5.000 4.000 3.000 2.000 1.000 0 1999 2000 2001 2002 2003 2004 2005
Abbildung 1.9: Die prognostizierte Entwicklung der Breitbandanschlsse in Deutschland (Quelle: Forrester Research, 2000)
35
2
2.1
VPN-Typen
Bei VPNs unterscheidet man, abhngig vom Einsatzgebiet, zwischen verschiedenen Arten, wobei diese durchaus auch miteinander kombiniert werden knnen. Die unterschiedlichen Arten von VPNs lehnen sich dabei stark an ihre korrespondierenden klassischen Netzwerkstrukturen an.
Remote-Access-VPN
Ein Remote-Access-VPN ermglicht es, von entfernten Systemen aus auf ein Unternehmensnetz zuzugreifen. Auf herkmmliche Weise erreicht man dies durch den Einsatz von RACs im Unternehmensnetz. Ein RAC (Remote Access Concentrator) ist ein System, das an ffentliche Telefonnetze angeschlossen wird und die analoge oder digitale Einwahl in diese Netze ermglicht. Standard-RACs terminieren Verbindungen unterschiedlicher Natur, wie zum Beispiel ISDN oder analoge Rufe ber Modems. Sie werden in der Regel, je nach Anzahl der maximal gleichzeitig zu terminierenden Verbindungen, ber einen oder mehrere Primrmultiplexanschlsse mit dem Telefonnetz verbunden. Diese Primrmultiplexanschlsse (PMX), in Deutschland als S2M-Anschluss bezeichnet, sind eine digitale, strukturierte 4-Draht-Verbindung mit einer Bandbreite von 2,048 Mbit/s. Sie besteht aus 30 Nutzdatenkanlen, einem Signalisierungskanal und einem Steuerungskanal, kann also gleichzeitig maximal 30 Whlverbindungen betreiben.
Analog
RemoteAccessKonzentrator
ISDNBRI
ISDN PSTN GSM
S2M
GSMV .110
Abbildung 2.1: Der Remote-Access-Konzentrator muss Verbindungen mit unterschiedlicher Technologie terminieren.
Intranet
37
2 VPN-Typen
Die RACs mssen technisch dafr ausgelegt sein, alle vorkommenden analogen und digitalen Protokolle verarbeiten zu knnen. In heutigen Systemen mssen Modemprotokolle wie V.90, V.34, V34+ und manchmal auch noch X.2 oder k56flex implementiert werden. Im digitalen Bereich mssen sowohl synchrones ISDN als auch asynchrone Varianten wie V.120 und, vor allem wenn eine Einwahl aus einem GSM-Netzwerk untersttzt werden soll, auch das V.110-Protokoll implementiert werden. In der Regel sollen auch noch alle Dienste unter einer einzigen Rufnummer erreichbar sein und erst im RAC unterschieden werden. Dies macht heutige Remote-Access-Konzentratoren technisch sehr komplex und damit auch meist sehr teuer. Weiterhin mssen solche Gerte auch skalierbar sein, da die Anzahl der bentigten Ports in der Regel stetig wchst. Skalierbarkeit bedeutet in diesem Kontext nicht nur, dass eine ausreichend groe Anzahl von Einwahlports verfgbar sein muss, sondern auch, dass die interne Verarbeitungskapazitt und die Anbindung an das Intranet ebenfalls mitwachsen mssen, andernfalls entsteht zunehmend ein Performance-Engpass. Somit sieht man sich mit einer Reihe von Anforderungen und den damit verbundenen Kosten konfrontiert, die einen Remote-Access-Dienst blicherweise sehr kostenintensiv machen: Man muss eine relativ teure Technologie zum Terminieren der verschiedenartigen Verbindungen aus dem ffentlichen Telefonnetz beschaffen und warten. Die Technologie muss stndig an neue technische Gegebenheiten und wachsende Kapazitten angepasst werden. Man zahlt eine vergleichsweise hohe Grundgebhr fr die bentigten Primrmultiplexanschlsse. Die Verbindungsgebhren sind ebenfalls hoch, insbesondere wenn hufig Verbindungen im Fernbereich oder gar internationale Verbindungen bentigt werden. Andere Dienste wie DSL (Digital Subscriber Line, Datenbertragung mit sehr hoher Geschwindigkeit ber Standardtelefonleitungen) oder Kabelmodems, die Daten ber Breitband-Fernsehkabel bertragen, sind mit RACs nicht zu verarbeiten und erfordern zustzlichen technischen Aufwand. Ein Remote-Access-VPN befasst sich mit genau diesen kritischen Faktoren, die einen Remote-Access-Dienst sehr teuer und aufwendig machen knnen. Sein Ziel ist es, die Hardware zum Terminieren der Verbindungen kostengnstig und einfach zu halten und die Verbindungsgebhren zu minimieren. Ein Remote-Access-VPN besteht aus einem VPN-Konzentrator, der die virtuellen Remote-Access-Verbindungen terminiert, und Software-Clients, die auf den entfernten Rechnern installiert werden, um die Verbindungen aufzu38
Remote-Access-VPN
bauen. In seltenen Fllen werden die Verbindungen auch erst im RAC des Internet Service Providers initiiert, so dass in diesem Fall auf dem Endgert keine spezielle Clientsoftware notwendig ist. Eine detaillierte Diskussion der Vor- und Nachteile dieser beiden Varianten finden Sie in Kapitel 6. An dieser Stelle sei aber schon festgestellt, dass die erstgenannte Variante, die mit der speziellen VPN-Clientsoftware, mittlerweile sehr verbreitet ist. Der VPNKonzentrator terminiert also nur logische Verbindungen, so genannte Tunnel. Die Anbindung zu einem Internet Service Provider erfolgt meist per LANInterface an einem Access-Router, den der Provider zur Verfgung stellt und betreibt, oder in Ausnahmefllen ber die WAN-Schnittstelle eines KundenRouters direkt zum Provider. Die Clients knnen sich mit beliebigen bertragungstechnologien mit einem Service Provider verbinden. Ob man Modems, ISDN, DSL oder Kabelmodems einsetzt, hngt lediglich davon ab, welche Zugangstechnologie die lokalen Service Provider in den jeweiligen Regionen anbieten. Der Endkunde selbst braucht kein zentrales Equipment zur Terminierung dieser Verbindungen mehr bereitzuhalten, dies erledigen die Service Provider. Der Kunde terminiert nur so genannte Tunnel, die vom Provider zu seinem VPN-Konzentrator aufgebaut werden. Auch eine steigende Anzahl von Benutzern ist damit zum Problem der ISPs geworden, die andererseits aber auch ein vitales Interesse daran haben, dass gengend Ports zur Verfgung stehen. Denn wer sich nicht bei einem Service Provider einwhlen kann, der beschert ihm auch keinen Umsatz.
Breitband-Kabel
Analog
ISDN BRI
Internet
DSL
GSM V.110
Abbildung 2.2: Der VPN-Konzentrator terminiert nur eine IP-Verbindung, die Einwahl der Clients erfolgt bei den Internet Service Providern.
Intranet
VPNKonzentrator
39
2 VPN-Typen
Bei den Gebhren ergeben sich mit einem Remote-Access-VPN erhebliche Kostenvorteile, insbesondere bei einer groen Flchendeckung oder bei internationalem Einsatz. Man baut nmlich keine Telefonverbindung vom Endgert zu einem zentralen RAC im Unternehmensnetz mehr auf, sondern nur noch eine Telefonverbindung zum nchstgelegenen RAC eines Internet Service Providers und dies meist zum Ortstarif oder zu speziellen Billigtarifen. In einigen Lndern sind Ortsgesprche umsonst, beziehungsweise bereits in der Grundgebhr des Anschlusses enthalten, ansonsten sind sie in der Regel recht preiswert. Auf jeden Fall sind sie aber billiger als die Gebhren fr Ferngesprche oder internationale Verbindungen. Bei Kostenvergleichen, die auf Anschlussgebhren, zeitabhngigen Tarifen, Entfernungszonen und Verbindungszeiten basieren, kann man Einsparungen im Bereich von 70 bis 80% erzielen. Bei den Gesamtsummen, die viele Unternehmen pro Jahr fr normalen Remote Access ausgeben, ist dies ein erhebliches Einsparpotenzial. Was hierbei nicht mit kalkuliert wurde, sind versteckte oder nicht deterministische Kosten wie Administration, Implementierung neuer Technologien, neue Gebhrenmodelle usw.
Intranet
Router B
Intranet
Abbildung 2.3: Die drei Standorte sind hier mit Festverbindungen redundant verbunden.
Ein weiterer wichtiger Punkt, den man beachten sollte, ist der deutlich geringere Port-Preis eines VPN-Konzentrators im Vergleich zu einem RAC. Ab einer Portzahl von einigen tausend Ports kostet ein VPN-Port bei einigen Herstellern weniger als 5% eines Remote-Access-Ports! Der Grund fr diesen krassen Preisunterschied liegt darin, dass VPN-Konzentratoren nicht eine Vielzahl von Technologien, wie Telefonsignalisierung, Modemprotokolle, Analogverarbeitung usw., implementieren mssen und daher von der Hardwarearchitektur vergleichsweise einfach aufzubauen sind. Es gibt Hersteller, die sogar Standard-PC-Architekturen mit Windows oder Unix als VPN-Konzentratoren benutzen, also berhaupt keine Hardware-Entwicklungskosten haben.
40
Intranet
Router A
Standardfestverbindungen
Router C
Branch-Office-VPN
Beim Einsatz einer VPN-Technologie, bei der die virtuelle Verbindung auf dem Client initiiert wird, ist man auch vllig unabhngig vom Internet Service Provider. Man kann ihn jederzeit wechseln oder auch problemlos mehrere ISPs gleichzeitig benutzen. Denn der Service Provider ist dann in keiner Weise mehr in die Funktion des VPN involviert, er terminiert lediglich Telefonanrufe und Festverbindungen und bertrgt IP-Pakete zwischen Endgerten und VPN-Konzentratoren.
2.2
Branch-Office-VPN
Branch-Office-VPNs ersetzen die herkmmlichen WAN-Verbindungen, mit denen man verschiedene Standorte oder Netzwerke in diesen Standorten miteinander verbindet. Der Begriff Branch-Office-VPN hat sich mittlerweile weitgehend fr diesen VPN-Typ durchgesetzt, gelegentlich spricht man auch von Site-to-Site-VPNs. Warum besteht berhaupt eine Notwendigkeit, bisherige Weitverkehrsnetze, die mit verbreiteten Technologien wie Standardfestverbindungen, Frame Relay oder ATM eingerichtet wurden, durch ein VPN zu ersetzen? Auch hier gibt es einen Hauptgrund, nmlich die hohen Kosten durch die relativ hohen Verbindungsgebhren. Ganz besonders dramatisch sind die Kosten, wenn die zu verbindenden Standorte sehr weit voneinander entfernt oder gar im Ausland liegen. Je nach Anzahl, Entfernung, bentigter Bandbreite und zu bertragender Datenmenge kommen da schnell sehr hohe Kosten zusammen. Tendenzen wie die Globalisierung, internationale Fusionen und Kooperationen sowie die ganzen neuen, so genannten E-Technologien (E-Business, E-Commerce usw.) fhren dazu, dass die Kosten fr die bentigte Datenkommunikation immer weiter in die Hhe schnellen. Der steigende Kostendruck zwingt auch im Weitverkehrsbereich immer mehr Unternehmen dazu, ihre eingesetzte WAN-Technologie neu zu berdenken und gegebenenfalls zu ndern, um konkurrenzfhig bleiben zu knnen. Als Ausweg aus dem Kostendilemma bieten sich zunehmend Branch-OfficeVPNs an (siehe Abbildung 2.4). Der Faktor, um den die bertragungskosten reduziert werden knnen, hngt im Wesentlichen von folgenden Faktoren ab: der Entfernung zwischen den Systemen, der bertragenen Datenmenge und der eingesetzten Technologie und Geschwindigkeit. Eingreifen kann eine VPN-Lsung hauptschlich beim ersten Faktor, nmlich bei der Entfernung zwischen den Standorten. Diese bleibt geografisch gesehen zwar nach wie vor bestehen, aber die kostenintensiven, direkten Verbindungen (Standardfestverbindung, Frame-Relay-PVC usw.) zwischen den privaten Netzen werden durch zwei sehr kurze Verbindungen zwischen den Standorten und den Zugangsknoten eines Internet Service Providers ersetzt. Die verbleibende Strecke zwischen diesen beiden POPs (Point of Presence, Zugangsknoten zum Internet) wird vom Internet berbrckt, ber das die Datenpakete sehr kostengnstig bertragen werden knnen.
41
2 VPN-Typen
Intranet
Internet
VPNGateway
Intranet
Virtuelle Verbindung (Tunnel)
Abbildung 2.4: Ein Branch-Office-VPN verbindet die drei Standorte redundant durch virtuelle Verbindungen (Tunnel) ber das Internet.
Das Einsparpotenzial ist hier nicht ganz so hoch wie bei Remote-AccessVPNs, es ist jedoch durchaus mglich, die Gebhren um bis zu 50% zu reduzieren, im internationalen Bereich sogar um noch mehr.
2.3
Extranet-VPN
Ein Extranet-VPN sieht von seiner Struktur her hnlich aus wie ein RemoteAccess- oder Branch-Office-VPN oder eine Kombination von beiden (siehe Abbildung 2.5). Der fundamentale Unterschied zu den beiden zuvor besprochenen VPNs liegt in der Natur der Teilnehmer. Ein VPN bildet ein rein privates Netzwerk ab, auf das nur Angehrige der eigenen Firma oder Organisation Zugriff haben und das nur eigene Standorte miteinander verbindet. Ein Extranet-VPN hingegen ffnet das private Netzwerk auch fr externe Personen oder Organisationen und gewhrt diesen (einen meist limitierten und kontrollierten) Zugriff auf Ressourcen im Unternehmensnetzwerk. Extranet-VPNs werden also auf der Basis der normalen VPN-Technologie aufgebaut, aber die Datenpakete stammen nicht von eigenen Mitarbeitern und mssen deshalb gesondert behandelt werden. Dies kann entweder das VPNGateway selbst tun, oder man bergibt die Pakete einem speziell dafr ausgelegten System, meist einer Firewall. In dem Beispiel in Abbildung 2.5 werden die Verbindungen zu eigenen Mitarbeitern im Intranet terminiert, die Verbindungen von der Partnerfirma jedoch auf einer Firewall. Fr den eigent-
42
Intranet
VPNGateway
VPNGateway
VPN-Service-Provider
lichen Datentransport wird das VPN benutzt. Die Firewall ist fr die besondere Behandlung der Extranet-Datenpakete zustndig, also fr die dynamische, zustandsabhngige Filterung, fr die Zugriffsbeschrnkung, das Auditing und das Logging.
Intranet
VPNGateway
VPNGateway
VPN Gateway
Firewall
FremdIntranet
Abbildung 2.5: Ein Extranet-VPN verbindet auch fremde Standorte oder Benutzer mit dem Intranet. Fr diese Verbindungen sind spezielle Sicherheitsregeln anzuwenden.
In Abbildung 2.5 sehen Sie die typische Struktur, in der moderne VPN-Konzentratoren und Firewalls miteinander kombiniert werden. In seltenen Fllen missbraucht man auch VPN-Konzentratoren als Firewalls und umgekehrt, aber da beide Systeme eine vllig andere, ja sogar gegenstzliche Funktionalitt aufweisen, vermeidet man dies in der Regel. In Kapitel 10 wird ausfhrlich auf die Kombinationsmglichkeiten von VPN-Gateways und Firewalls eingegangen.
2.4
Bei diesen Arten von VPNs, Remote Access, Branch Office und Extranet, hat man die Wahl, sein VPN selbst aufzubauen oder in verschieden starkem Mae so genannte VPN-Dienste von Service Providern oder Carriern zu benutzen. Das kann man in verschiedenen Abstufungen tun, je nachdem wie stark man sich an einen Provider binden will.
Intranet
Internet
43
2 VPN-Typen
2.4.1
IP-VPN-Dienste
IP-VPNs arbeiten mit virtuellen IP-Verbindungen. Die Endpunkte dieser Verbindungen (Tunnel) sind die IP-Schnittstellen von Routern, VPN-Gateways oder VPN-Clientsystemen. Dies ermglicht, wie Sie in Abbildung 2.6 sehen, sowohl einen VPN-Betrieb vollstndig in Eigenregie, also ganz ohne Mitwirkung eines Providers, als auch ein vollstndiges Outsourcing und alle mglichen Zwischenstufen.
Carrier VPNGateway AccessRouter Carrier AccessRouter VPNGateway
ISP Service Provider Service Provider Service Provider Service Provider Kunde Kunde
Kunde Kunde Kunde
Internet
Kunde Kunde
Kunde
Abbildung 2.6: Die verschiedenen Stufen von IP-VPN-Diensten und der Grad der Beteiligung durch Kunde, Service Provider und Carrier.
Vollstndiger Eigenbetrieb des VPN In diesem Fall ist der Service Provider in keiner Weise in den Betrieb des VPN involviert. Er stellt dem Kunden lediglich einen Internetzugang zur Verfgung. Der Kunde beschafft und betreibt seine Access-Router und VPN-Gateways selbst. Das User- und Gruppenmanagement, ebenso wie die Systemkonfigurationen, liegen im Verantwortungsbereich des Kunden. Die Nachteile dieser Lsung sind der relativ hohe Aufwand fr den Kunden und die vielen verschiedenen Schnittstellen. Denn hier sind mindestens drei Organisationen beteiligt: Der Endkunde (Intranet und VPN), ein Carrier (Last-Mile-bertragung) und ein Service Provider (Access-Router und Internetzugang). Bei Problemen kann es dabei zum allseits bekannten Hin- und Herschieben der Verantwortung kommen.
44
Der Vorteil aus der Sicht des Kunden ist der, dass keine Bindung an einen Provider ntig ist und jederzeit zu einem anderen gewechselt werden kann. Access-Equipment-Outsourcing In diesem Fall wird vom Service Provider ein etwas greres Leistungspaket gekauft, denn er ist in dieser Variante fr die vollstndige Kommunikation zwischen seiner Infrastruktur und einem fest definierten Punkt, meist dem LAN-Interface seines Access-Routers, verantwortlich. Der Kunde beschafft und betreibt lediglich seine VPN-Gateways, die ber einen LAN-Anschluss mit den Access-Routern des Service Providers verbunden werden. Somit ist der Nachteil der vielen Schnittstellen fr den Kunden entschrft, denn er hat nur noch einen Ansprechpartner, seinen Service Provider, falls die Weitverkehrsverbindung nicht funktioniert. Seine Vorteile bleiben auch noch weitgehend bestehen, ein Wechsel ist auch hier nicht so kompliziert. In diesem Modell ist der Service Provider in keiner Weise in den VPN-Betrieb involviert. VPN- und Access-Equipment-Outsourcing Dies ndert sich jedoch mit dieser Variante. Hier werden neben den AccessRoutern und der Verbindungsinfrastruktur auch die VPN-Systeme vom Provider gestellt. Der Zugriff auf die VPN-Systeme durch den Service Provider beschrnkt sich jedoch auf die reine Systemkonfiguration. Das VPN-Management, also die Konfiguration von Tunneln, Sicherheitseinstellungen, Gruppen, Benutzern usw. obliegt ausschlielich dem Kunden. Dies erfordert aber unbedingt VPN-Gateways, die ein spezielles SplitManagement ermglichen, das diese beiden Funktionen sauber trennen kann.
Big Brother Dies hat auch vor allem rechtliche Grnde. Denn in Deutschland sind Carrier und Service Provider verpflichtet, in ihren Kommunikationsnetzen den Ermittlungsbehrden im Bedarfsfall, der allerdings eine richterliche Genehmigung bedingt, eine technische Mglichkeit zum Abhren (Lauschangriff) zur Verfgung zu stellen. In Internet-VPNs wird jedoch aus Sicherheitsgrnden fast ausschlielich IP Security (IPSec) mit starker Verschlsselung eingesetzt. Wie Sie in Kapitel 7 und 8 erfahren, ist IPSec jedoch so zu implementieren, dass weder eine Schlsselhinterlegung noch eine Schlsselrckgewinnung mglich ist. Demnach kann ein Service Provider oder Carrier Abhrmanahmen nur dadurch ermglichen, dass er die IPSec-Verschlsselung ganz abschaltet, indem er die Sicherheitsstrategie im VPN-Gateway entsprechend ndert.
45
2 VPN-Typen
Da ein Abhren aber nur dann Sinn macht, wenn der Abgehrte nichts darber wei, darf der Service Provider seinen Kunden auch nicht darber informieren und kommt damit in Teufels Kche, denn die Pakete, die dann ja alle unverschlsselt durch das Internet transportiert werden, knnen dadurch auch von anderen, nicht berechtigten Personen abgehrt werden. Das Split-Management ist ein mglicher Ausweg aus diesem Dilemma. Denn Endanwender, also Firmen oder Privatpersonen, drfen, zumindest in Deutschland, nach Belieben verschlsseln. Auf diese Weise kann der Service Provider oder Carrier dem Kunden ein VPN-Gateway zur Verfgung stellen und teilweise auch managen; der Kunde hat jedoch ein anderes Management-Interface und kann seine Benutzer, Gruppen und Tunnel mit der geeigneten Verschlsselung konfigurieren. Vollstndiges VPN-Outsourcing Dieses Modell ist fr den Kunden mit dem geringsten Aufwand verknpft, denn der vollstndige Betrieb des VPN wird vom Service Provider durchgefhrt inklusive der Benutzerverwaltung. Der Nachteil ist der, dass hier eine sehr starke Abhngigkeit vom Provider gegeben ist und ein Wechsel zu einem anderen Provider mit sehr hohem Aufwand verbunden ist. Auerdem behalten viele Kunden aus Sicherheitsgrnden die Verwaltung ihrer Benutzer und die Einstellungen fr die Verschlsselungsstrke lieber in eigener Hand.
2.4.2
Layer-2-VPN-Dienste
Layer-2-VPNs werden fast ausschlielich dazu benutzt, virtuelle PPP-Verbindungen zu betreiben. Wie dies technisch umgesetzt wird, ist ausfhrlich in den Kapiteln 6 und 9 beschrieben. Der Sinn dieses Vorgehens besteht darin, seinen Einwhldienst nicht mehr selbst zu betreiben. Die Service Provider haben in der Regel eine gut ausgebaute Einwhl-Infrastruktur mit einer Vielzahl von POPs, in die sich Kunden zu sehr gnstigen Tarifen einwhlen knnen. Beim Layer-2-VPN werden in diesen POPs jedoch nur die Telefonverbindungen terminiert, die Datenverbindungen selbst werden zum VPN-Gateway des Kunden gefhrt (getunnelt). Der Vorteil fr den Kunden ist vor allem der, dass er sehr viele Kosten einsparen kann, sowohl im Tarifbereich als auch beim Management. Statt teurer Remote-Access-Konzentratoren bentigt er nur ein dazu vergleichsweise kostengnstiges VPN-Gateway. Im unteren Teil von Abbildung 2.7 sehen Sie das Prinzip eines solchen Layer2-VPN-Dienstes. Die Remote-Access-Clients whlen sich in den POP eines Internet Service Providers ein. Sie geben dazu eine spezielle zweiteilige User-
46
Intranet-VPN
ID ein, von der ein Teil vom ISP ausgewertet wird, damit dieser erkennen kann, wohin die virtuelle Verbindung durch einen Tunnel zu fhren ist. Der zweite Teil der User-ID dient dazu, den Benutzer im VPN-Gateway des Kunden zu authentifizieren.
Abbildung 2.7: Layer-2-VPN-Dienste werden meist fr Remote-Access-VPNs eingesetzt.
Natrlich gibt es auch die Mglichkeit, Branch-Office-VPNs auf diese Weise aufzubauen. Hierbei werden statt der Whlverbindungen feste Verbindungen eingesetzt und die Tunnel in der Regel auch statisch konfiguriert.
2.5
Intranet-VPN
Ein Intranet-VPN ist ein spezielles VPN, das dem allgemeinen Begriff eines virtuellen privaten Netzwerks nmlich der Verwendung eines ffentlichen Netzwerks zum Transport privater Daten sogar ein wenig widerspricht. Hier werden nicht auf einem ffentlichen, sondern auf einem privaten, meist lokalen Netzwerk verschiedene logische Netzwerke auf der OSI-Ebene 2 (Sicherungsschicht) oder 3 (Vermittlungsschicht) abgebildet. Solch ein Konstrukt verwendet man meist, um bestimmte Gruppen oder Organisationsein-
47
2 VPN-Typen
heiten auf Netzwerkbasis voneinander zu trennen und ihnen eine eigene Netzwerkinfrastruktur zur Verfgung zu stellen. Dies kann man auf verschiedene Weise realisieren: VLANs VLANs nach IEEE802.1q IP-Tunneling
2.5.1
Virtual Local Area Network (VLAN)
Das VPN wird hierbei durch Erweiterungen der in lokalen Netzwerken (LAN) eingesetzten Switching-Technologien erzeugt. Die virtuellen Netzwerke werden auf der OSI-Schicht 2 abgebildet. Das LAN-Switching wurde ursprnglich eingefhrt, um den Durchsatz in Shared-Media-Netzen wie dem Ethernet zu erhhen, indem diese Netze in verschiedene, so genannte Collision Domains aufgeteilt werden. Die Switches verbinden diese Collision Domains, um die Pakete weiterzuleiten, die an Stationen in der gleichen Collision Domain in dem gleichen oder in einem anderen Switch adressiert sind. Die in den LAN-Switches eingesetzte Technologie geht nun noch einen Schritt weiter und erlaubt es dem Netzwerkadministrator, eine logische Gruppe von Gerten im gesamten lokalen Netzwerk zu definieren, die dann ein virtuelles LAN (VLAN) bilden. Dieses VLAN kann sich auch ber mehrere Switches hinweg erstrecken. In der VLAN-Technologie werden keine speziellen Sicherheitstechnologien, wie Verschlsselung, Integrittssicherung oder Paketauthentifizierung eingesetzt. Es erfolgt jeweils eine Trennung des Transports der Datenpakete auf der OSI-Schicht 2, und statt auf Sicherheit wurde bei dieser Technologie mehr auf Performance abgezielt. Die Erzeugung eines solchen virtuellen LANs kann je nach gewnschtem Einsatz auf verschiedene Weise erfolgen, woraus auch die Bezeichnung der jeweiligen Art des VLANs abgeleitet wird. Viele moderne Switch-Architekturen beherrschen alle Spielarten der VLAN-Technologie und knnen sogar routen. Ein so genannter Layer-3-Switch trifft seine Weiterleitungsentscheidungen extrem schnell und routet mit wire speed, mittlerweile auch im GigabitBereich. Protokollbasierende VLANs Bei VLANs, die auf Informationen der OSI-Schicht 3, also der Vermittlungsschicht, beruhen, spricht man von protokollbasierenden VLANs. Die Aufteilung der flachen LAN-Topologie in logische Gruppen erfolgt auf Basis von Kennzeichen, die aus den Informationen des Schicht-3-Headers gewonnen
48
Intranet-VPN
werden. Es knnen virtuelle Netze aufgrund des Typs der Protokolle (z.B. IP, IPX oder AppleTalk) unterschieden werden, oder man gruppiert auf Basis von IP-Subnetzen.
PC1 PC9
PC2 PC3 PC4 PC5 PC6 PC7 PC8
Layer 2 Switch
1 2 3 4 5 6 7 8 Trunkverbindung
Layer 2 Switch
1 2 3 4 5 6 7 8
PC10 PC11 PC12 PC13 PC14 PC15 PC16
V-LAN-Mitgliedschaft V-LAN 1 V-LAN 2 V-LAN 3 PC1 PC3 PC5 PC2 PC7 PC8 PC4 PC6 PC13 PC14 PC15 PC16
PC11 PC12 PC9 PC10
Abbildung 2.8: Ein VLAN, in dem die Zugehrigkeit zu einem virtuellen LAN von der Portnummer des Layer-2-Switchs abhngig ist.
Der Vorteil dieser Variante ist der, dass ein Gert unabhngig von seiner MAC-Adresse (MAC, Media Access Control, Schicht-2-Adresse der Endstation) an mehreren VLANs partizipieren kann. Es besteht auch keine Notwendigkeit, spezielle VLAN-Informationen in den Header einzufgen (so genanntes Frame Tagging). Falls man eine Gruppierung auf Basis von IP-Subnetzen vornimmt, entfllt auch die in groen Netzen aufwendige Zuordnung jedes Endgertes zu einem VLAN, da diese implizit durch den IP-Header erfolgt. Die Nachteile dieser Lsung sind unter anderem, dass die Auswertung der Layer-3-Informationen einiges an Performance verbraucht, dass man auf routbare Protokolle wie IP oder IPX angewiesen ist und dass der Einsatz zusammen mit DHCP (Dynamic Host Configuration Protocol, ein Verfahren, das Interface-Parameter wie IP-Adressen dynamisch beim Systemstart zuweist) in der Regel nicht mglich ist.
49
2 VPN-Typen
Portbasierende VLANs Bei diesem Ansatz werden die Gruppen auf der Basis von physikalischen Ports auf einem oder mehreren LAN-Switches definiert. Hierbei ordnet der Netzwerkadministrator manuell die Ports einem virtuellen LAN zu. Dies bedeutet auch, dass die VLANs vllig voneinander isoliert sind und nur auf der OSIEbene 3, also ber einen Router, miteinander kommunizieren knnen. blicherweise kann ein Port nur einem einzigen VLAN zugeordnet werden, was auch einsichtig ist, denn es ist gemeinhin auch nicht mglich, einen Port gleichzeitig mehreren realen LANs zuzuweisen. Diese Art von VLAN ist relativ einfach zu verstehen und zu managen. Sie ist auf der anderen Seite aber mit einem gewissen Aufwand verbunden, da jeder Port manuell konfiguriert werden muss. Ein weiterer Nachteil tritt in Erscheinung, wenn ein Benutzer umzieht: Der Administrator muss dessen System auf dem Switch umkonfigurieren. MAC-Adressen-basierende VLANs Hier erfolgt die Zuordnung der Endgerte zu einem VLAN aufgrund der MAC-Adresse des jeweiligen Systems. Der Administrator pflegt hierfr Tabellen, in denen die Zuordnungen von MAC-Adressen zu VLANs abgelegt sind. Die Ports der LAN-Switches werden dynamisch einem VLAN zugewiesen, sobald sie einen Frame erhalten haben, der die notwendigen Kriterien erfllt. Vom Standpunkt der Sicherheit aus betrachtet, sind MAC-basierende VLANs die sicherste der drei Varianten, da es sehr schwer ist, eine MAC-Adresse zu spoofen. Unter Spoofing versteht man das Vortuschen einer anderen Adresse. Der Hauptvorteil hierbei ist der, dass die Zugehrigkeit zu einem VLAN bestehen bleibt, auch wenn der Benutzer mit seinem Gert umzieht, da die MAC-Adresse in seiner Netzwerkkarte fest konfiguriert ist. Allerdings weist diese Variante eine Reihe von Nachteilen auf, vor allem im Bereich der Switch-Performance auf bestimmten Ports, auf denen mehrere MAC-Adressen in verschiedenen VLANs vorkommen. Weiterhin muss das VLAN bei Austausch von Netzwerkkarten in den Endstationen rekonfiguriert werden.
2.5.2
VLANs nach IEEE802.1q
Der relative neue Standard IEEE802.1q definiert im Ethernet-Header unter anderem ein Feld (Tag-Feld), in dem eine so genannte VLAN-ID (VID) mit zwlf Bit Lnge enthalten ist und das somit insgesamt 4096 verschiedene VLANs unterscheiden kann. Viel wichtiger in diesem Zusammenhang ist
50
Intranet-VPN
aber die Tatsache, dass die drei anderen VLAN-Varianten von Hersteller zu Hersteller unterschiedlich implementiert werden und dass nunmehr ein verbindlicher IEEE-Standard verabschiedet wurde. Somit kann ein VLAN auch mit Systemen unterschiedlicher Hersteller aufgebaut werden.
0 31 Ethernet-Prambel Ethernet-Zieladresse Quelladresse Lngen-/T ypfeld 63 Delim. EthernetDatenfeld
IEEE802.3-Ethernet-Header
0 31 Ethernet-Prambel Ethernet-Zieladresse Quelladresse Altes Lngen-/ Typfeld Typfeld Datenfeld Delim. EthernetTag-Feld 63
IEEE802.1q-Ethernet-Header Tag-Feld
Abbildung 2.9: Im IEEE802.1q-Standard ist der Ethernet-Header um vier Byte erweitert.
Ein Nachteil, der nicht bei VLANs auftritt, die auf Layer-3-Protokollinformationen basieren, ist der, dass die VLAN-Informationen beim Transport ber Router verloren gehen. Eine Lsungsmglichkeit wre in diesem Fall der Einsatz der LAN-Emulation von ATM, da hierbei die Layer-2-Informationen erhalten bleiben. Ein Switch, der VLANs nach IEEE802.1.q untersttzt, kennt grundstzlich drei Arten von Links: Trunks Access Links Hybrid Links
51
2 VPN-Typen
Trunks Auf diesen Ports werden Frames mit einem VLAN-Tag bertragen. Sie werden meist dazu benutzt, Switches miteinander zu verbinden. Access Links An diese Ports werden Systeme angeschlossen, die selbst kein IEEE802.1q untersttzen, zum Beispiel PCs, ltere Hubs usw. Die VLAN-ID wird eingehenden Frames erst im Switch zugewiesen. Bei ausgehenden Frames muss der Switch das Tag-Feld entfernen. Hybrid Links Da zunehmend mehr Endgerte IEEE802.1q untersttzen werden, gibt es so genannte Hybrid Links, die sowohl Frames mit als auch ohne Tag-Feld verarbeiten knnen.
2.5.3
IP-Tunneling
Beim Einsatz der Tunneling-Technologie braucht man beim Aufbau seines VPNs die Netzwerkinfrastruktur, also Switches, Hubs usw., berhaupt nicht an die Gegebenheiten des geplanten virtuellen Netzwerks anzupassen. Hier wird ausschlielich auf der IP-Ebene gearbeitet, und es werden die gleichen Technologien und Systeme verwendet, die auch in normalen VPNs, also solchen, die ffentliche IP-Netze benutzen, zum Einsatz kommen.
52
3
3.1
Anforderungen an VPNs
Die Einsatzgebiete fr virtuelle private Netzwerke sind sehr vielfltig. Je nach den gestellten Anforderungen an Sicherheit, Quality-of-Service sowie anderen Rahmenbedingungen kann man, entsprechend dem Angebot der Service Provider, die komplette Weitverkehrsinfrastruktur, die eigene Business-toBusiness-Kommunikation (B2B) und den Remote Access als virtuelles privates Netzwerk aufbauen. Bei der Auswahl der geeigneten Technologie muss man sehr genau untersuchen, welche Anforderungen an das VPN gestellt werden. In der Regel resultieren diese aus Sicherheitsbedrfnissen, gefolgt von Kostenaspekten, der Verfgbarkeit und abhngig von den eingesetzten Applikationen den bentigten Bandbreiten und tolerierbaren Verzgerungszeiten.
Sicherheit
Im Bereich der Datensicherheit gibt es eine ganze Reihe von Anforderungen, die sich in verschiedene Bereiche gliedern: Datenvertraulichkeit Schlsselmanagement Paket-Authentifizierung Datenintegritt Benutzer-Authentifizierung Benutzer-Autorisierung Schutz vor Sabotage Schutz vor unerlaubtem Eindringen
3.1.1
Datenvertraulichkeit
Es muss sichergestellt werden, dass Unbefugte die Daten auf ihrem Weg durch das Internet nicht lesen knnen. Vielfach wird auch gefordert, dass das interne Netzwerk mit seinen Verkehrsbeziehungen (Quell- und Zieladressen, Protokoll- und Portnummern) ebenfalls nicht ausgespht werden kann. Dies wird im allgemeinen durch die Ver-
53
3 Anforderungen an VPNs
schlsselung der Paketdaten erreicht. Falls die Verkehrsbeziehungen ebenfalls geschtzt werden sollen, muss das originale Paket vollstndig in den Datenbereich eines neuen Pakets eingepackt werden. Dies nennt man Tunneling. Als Verschlsselungsverfahren sollten unbedingt standardisierte, wohl bekannte Verfahren wie DES (Data Encryption Standard, ein standardisiertes, weltweit eingesetztes Verschlsselungsverfahren) oder Triple-DES eingesetzt werden. Meist gibt die eingesetzte VPN-Technologie aus Grnden der Interoperabilitt die Verfahren auch schon fest vor. In der Praxis werden wegen ihrer hohen Geschwindigkeit ausschlielich so genannte symmetrische Verfahren eingesetzt, bei denen Sender und Empfnger den gleichen Schlssel zum Ver- und Entschlsseln der Daten bentigen.
3.1.2
Schlsselmanagement
Um auf sicherem und vor allem automatischem Wege eine Verteilung von symmetrischen Schlsseln zu ermglichen, bentigt man ein zuverlssiges Schlsselmanagement. Dessen Aufgabe besteht im Erzeugen aller bentigten Schlssel zur Verschlsselung, Integrittsprfung und Authentifizierung und in deren Verteilung zu den richtigen Gegenstellen in einem VPN (siehe Abbildung 3.1).
VPN-Client
Intranet
Internet
Tunnel
VPN-Konzentrator
VPN-Client
Tunnel
Paket-Verschlsselung Paket-Authentifizierung Paket-Integrittsprfung
Abbildung 3.1: Beim Transport privater Daten ber das Internet mssen verschiedene Sicherheitsaspekte bercksichtigt werden.
Gute Schlssel, vor allem solche zur Datenverschlsselung, haben eine relativ kurze Lebensdauer von meist einer Session oder wenigen Stunden und mssen deshalb sehr oft erzeugt und verteilt werden. Manuelle Verfahren scheiden aus diesem Grund, vor allem auch bei greren Installationen aus. Da Out-ofBand-Verfahren, also die Verteilung der Schlssel ber ein anderes Kommunikationsmedium, praktisch den doppelten Aufwand bei der Auslegung eines Netzes erfordern, scheiden diese ebenfalls in den meisten Fllen aus.
54
Sicherheit
Die heute bekannten Verfahren zum Schlsselmanagement basieren meist auf so genannten asymmetrischen Verfahren, bei denen zum Ver- und Entschlsseln jeweils unterschiedliche Schlssel verwendet werden, von denen einer, der ffentliche Schlssel (Public Key), allgemein bekannt sein darf. Diese Verfahren nennt man daher auch Public-Key-Verfahren.
3.1.3
Paket-Authentifizierung
Es muss garantiert werden, dass ankommende Pakete auch tatschlich von dem authentischen Sender kommen und nicht von Dritten mit geflschten Absenderadressen und neu berechneten Prfsummen geschickt wurden. hnlich wie bei einer Benutzer-Authentifzierung muss tatschlich jedes ankommende Paket authentifiziert werden, was man durch symmetrische Schlssel oder so genannte Pre-Shared Secrets, vertrauliche Daten, die nur dem Sender und dem Empfnger bekannt sind, erreicht. Aus Grnden der Geschwindigkeit und der Einfachheit kombiniert man dies meist mit Verfahren zur Prfung der Datenintegritt.
3.1.4
Datenintegritt
Der Empfnger muss zuverlssig erkennen knnen, ob ein ankommendes Paket whrend des Transports verndert wurde. Normale Prfsummenverfahren reichen hierfr nicht aus, da ein Angreifer nach nderung eines Datenpakets auch dessen Prfsumme neu berechnen kann. Spezielle Verfahren auf Basis von symmetrischen Verschlsselungsverfahren berechnen die Paketprfsumme und fgen sie in das Paket mit ein. Die Schlssel sind nur dem Sender und dem Empfnger bekannt. Ein Angreifer, der ein Paket ndern will, kann die Prfsumme nicht korrekt berechnen.
Intranet
VPN-Konzentrator VPN-Client
Internet
Tunnel
System-Authentifizierung
Benutzer-Authentifizierung
Abbildung 3.2: Neben der Verbindung selbst muss beim Remote Access auch der Benutzer authentifiziert werden.
55
3.1.5
Dies ist ganz wichtig bei Remote-Access-VPNs. Ein Benutzer, der ber ein VPN-Gateway Zugriff auf das Intranet verlangt, muss seine Identitt mglichst zuverlssig nachweisen. Der Grad dieser Zuverlssigkeit ist von Fall zu Fall verschieden, so dass ein guter VPN-Konzentrator eine Reihe unterschiedlich starker Authentifizierungsverfahren untersttzen muss. Die Abstufung reicht dabei von einfachen Passwortverfahren bis hin zur Verwendung von Tokenkarten oder digitalen Zertifikaten. In diesem Bereich, zum Beispiel bei den Tokenkarten, gibt es keine verbindlichen Standards, so dass man hier immer proprietr ist. Fr PKIs (Public Key Infrastructure, eine Infrastruktur zum Management von ffentlichen Schlsseln und digitalen Zertifikaten) gibt es eine Arbeitsgruppe innerhalb der IETF, die auch schon eine Reihe von Standards hervorgebracht hat.
3.1.6
Benutzer-Autorisierung
Wird das VPN auch als Extranet verwendet, dann greifen auch externe Personen oder Organisationen, denen nur begrenzte Zugriffsrechte gewhrt werden drfen, auf Ressourcen des Unternehmensnetzes zu. Die Autorisierung ist aber nur begrenzt ein Thema fr Zugriffssysteme wie Router oder VPN-Konzentratoren. Denn diese Systeme sind nicht in der Lage, auf Benutzer- oder Gruppenebene rollenbasierende Zugriffe auf Verzeichnisse, Datenbanktabellen oder Drucker zu steuern. Diese Funktionen knnen nur von den Systemen wahrgenommen werden, die diese Ressourcen auch verwalten, also von Betriebssystemen und Datenbankmanagementsystemen. Zugriffssysteme mssen aber die Fhigkeit besitzen, auf der Ebene von Netzwerkprotokollen eine Filterung vorzunehmen. Im Fall des IP-Protokolls heit dies, dass aufgrund von Host- oder Netzwerkadressen, Protokollnummern, Portnummern usw. Entscheidungen getroffen werden knnen, ob ein Paket weitergeleitet oder verworfen wird. Aber dies ist keine Filterung auf Benutzerebene mehr, sondern auf Netzwerkebene, da Benutzer normalerweise nicht an feste IP-Adressen gebunden sind. Falls die Filterungen auch aufgrund von Informationen in hheren Ebenen des OSI-Referenzmodells vorgenommen werden sollen, spricht man von Firewalls. Diese wurden bisher meist als bergangspunkt vom Intranet in das Internet verwendet, sind aber auch als Schutzsystem im Intranet-Extranetbergang einsetzbar. Firewalls bieten eine Filterung von Netzwerkpaketen bis hin zu Dateninhalten, Gateways auf Applikationsebene und Integrationsmglichkeiten von externen Applikationen wie z.B. Virenschutzprogramme. Manche Router oder VPN-Konzentratoren bieten als Option die Mglichkeit, Firewalls zu integrieren, jedoch ist es aus Grnden der Sicherheit und Performance oft besser, beide Funktionalitten strikt voneinander zu trennen.
56
Sicherheit
3.1.7
Schutz vor Sabotage
Das VPN-Gateway soll vor Angriffen sicher sein, die darauf abzielen, seine Funktionalitt zu beeintrchtigen oder es funktionsunfhig zu machen. Es gibt eine Reihe mehr oder weniger subtiler Arten von Angriffen auf Internetsysteme, denen auch VPN-Gateways ausgesetzt sein knnen. Vor der plumpsten Art einer solchen DoS-Attacke (Denial-of-Service, dabei wird verhindert, dass ein System seine Dienste erbringen kann), dem berlasten einer bertragungsstrecke oder einer Netzwerkschnittstelle, kann man sich nicht schtzen, allerdings sind solche Angriffe mittlerweile sehr schnell zurckzuverfolgen, und der Angreifer bekommt in der Folge sehr viel Zeit, um ber seine Untaten nachzudenken. Die Strafverfolgungsbehrden haben sich mittlerweile auf der ganzen Welt recht gut auf diese Art von Kriminalitt eingestellt. Subtilere Angriffe verschleiern, teilweise recht effizient, ihren eigentlichen Ursprung und schicken wenige, unverdchtig scheinende Pakete zu den Zielsystemen. Sie versuchen sie damit zu umfangreichen Aktivitten zu bewegen, aufgrund derer ihnen fr ihre eigentlichen Dienstleistungen immer weniger Ressourcen zur Verfgung stehen. So genannte DDoS-Angriffe (Distributed DoS) gehen noch einen Schritt weiter und legen ihren Angriff zweistufig an. Im ersten Schritt wird auf einer groen Anzahl von Rechnern unbemerkt ein Programm aufgespielt, das die eigentliche Attacke durchfhren soll. Als Nchstes fangen alle diese Rechner zu einem bestimmten Zeitpunkt an, gleichzeitig mit unverdchtig scheinenden Paketen das Zielsystem regelrecht zu bombardieren. Die Zurckverfolgung des Angriffs ist sehr schwer, da er von Hunderten oder Tausenden weltweit verteilter Systeme auszugehen scheint, diese aber selbst auch nur Opfer sind. Der wirkliche Urheber hat inzwischen genug Zeit gehabt, seine Spuren zu verwischen.
3.1.8
Schutz vor unerlaubtem Eindringen
Ein VPN-Gateway muss verhindern, dass Unbefugte die Mglichkeit haben, ber seine ffentlichen Schnittstellen in das Unternehmensnetzwerk zu gelangen. Denn dies ist der direkte Weg zu den Informationen, die ein Angreifer ausspionieren oder manipulieren will. Der Hacker begngt sich nicht mit dem, was ber Netzwerkverbindungen bertragen wird, sondern er will Zugang zu den Systemen, auf denen die Daten gespeichert und verarbeitet werden. Ganz beliebte Systeme sind Authentifizierungssysteme, auf denen Passwrter und andere kritische Informationen gespeichert werden. Wer solch ein System geknackt hat, dem steht ein ganzes Unternehmensnetzwerk offen.
57
Da VPN-Gateways in vielen Fllen die einzige Schnittstelle zwischen einem Intranet und dem Internet sind, auf das Millionen Unbekannte Zugriff haben, mssen hier besondere Manahmen zum Zugriffsschutz getroffen werden. Man unterscheidet dabei: Physische Sicherheit Interface-Sicherheit Betriebssicherheit Physische Sicherheit Die Systeme mssen in sicheren Umgebungen betrieben werden. Die Sicherheit des Betriebsraums ist wesentlich, Security-Gateways drfen nicht in Bros oder normalen EDV-Rumen betrieben werden, sondern nur in entsprechend sicheren Zonen. Sehr gute Systeme sind durch spezielle Manahmen gegen unerlaubtes ffnen des Gerts abgesichert und erzeugen im Zugriffsfall einen entsprechenden Alarm im Netzwerkmanagementsystem. Interface-Sicherheit Die Interfaces, die mit dem Internet verbunden sind, sollten spezielle Mechanismen zum Schutz gegen die verschiedenen Arten von Angriffen aufweisen. Als besonders geeignet erweisen sich so genannte gehrtete IP-Stacks, die eines groen Teils ihrer normalen Funktionalitt beraubt und damit gegen eine ganze Reihe von Angriffen immun sind, da die meisten Angriffspunkte berhaupt nicht mehr vorhanden sind. Als schlecht im Sinne von unsicher sind im Allgemeinen VPN-Systeme einzustufen, die als Programm oder Prozess auf nicht sicheren Betriebssystemen laufen. Trotz anders lautender Behauptungen kann die Sicherheit eines Programms nicht grer als die Sicherheit des Betriebssystems sein, auf dem es luft. Insbesondere die IP-Stacks vieler Betriebssysteme sind beliebte Ziele von Angriffen verschiedenster Art. Betriebssicherheit Hier gilt es dafr Sorge zu tragen, dass sich durch den Betrieb des VPN-Gateways keine Hintertren fr Angreifer ffnen. Da verschiedenen Studien zufolge der weitaus grte Teil von Angriffen von innen heraus erfolgt und nicht vonseiten des Internets, sind hier spezielle Manahmen ntig. Insbesondere sollte die Administration der Systeme im LAN verschlsselt erfolgen, also zum Beispiel mit SSL oder noch besser mit IPSec. berhaupt sollte man sich ganz genau vergewissern, welche Zugriffsmglichkeiten im privaten Netz gegeben sind und wie damit umzugehen ist. Ein cleverer Angreifer und viele davon sind sehr clever wird, sobald er sieht, dass ein VPN bei-
58
Verfgbarkeit
spielsweise IPSec mit starker Verschlsselung benutzt, sofort alle Gedanken an einen Angriff auf die IPSec-Verbindung selbst aufgeben und nach anderen Schwachstellen im System suchen. Und eben diese gilt es zu vermeiden.
3.2
Verfgbarkeit
Ein virtuelles privates Netzwerk soll traditionelle Weitverkehrs- oder Remote-Access-Lsungen ergnzen oder sogar ganz ersetzen. Dies bedeutet aber auch, dass ein VPN eine Verfgbarkeit bieten muss, die nicht unter der von herkmmlichen WAN-Infrastrukturen liegt. Die alten Lsungen, die auf Standardfestverbindungen, Frame Relay und ISDN basieren, weisen in der Regel eine hohe Verfgbarkeit auf.
3.2.1
Die Verfgbarkeit von Whlverbindungen
Der Remote Access wird ber entsprechende PC-Karten oder externe Gerte mittels Whlverbindungen ber das analoge oder digitale Fernsprechnetz, bei Bedarf auch ber das Mobilfunknetz, aufgebaut und in einem RemoteAccess-Konzentrator terminiert. Diese Netze bieten in der Regel Verfgbarkeitszeiten von mindestens 99,999%. Mit anderen Worten, das Netzwerk zwischen der ISDN-Karte im Notebook eines Auendienstmitarbeiters und dem Primrmultiplexanschluss seines Unternehmens fllt pro Jahr maximal 5,2 Minuten aus! An dieser Stelle auch gleich eine Anmerkung zum Begriff der Verfgbarkeit: Der obige Wert bedeutet nicht, dass das Netz im Jahr im Schnitt 5,2 Minuten ausfllt, sondern dass es garantiert nicht lnger als 5,2 Minuten auer Betrieb ist. Bei den in solchen Netzen eingesetzten Hochverfgbarkeitssystemen ist es nicht selten der Fall, dass sie jahrelang berhaupt nicht ausfallen. Fr viele Remote-Access-Infrastrukturen ist die so genannte Niemals besetztEigenschaft eines Telefonnetzwerks ebenso wichtig. Haben Sie schon jemals am soeben abgehobenen Hrer eines am ffentlichen Fernsprechnetz angeschlossenen, funktionsfhigen Telefonapparates kein Freizeichen gehrt? Vermutlich nicht. Wenn nun mehr Zugangskanle in ein Unternehmensnetzwerk gelegt werden, als es potenzielle Benutzer gibt, kann man sich damit eine RemoteAccess-Lsung mit tatschlich garantiertem Zugriff aufbauen, da man selbst Einfluss auf die Auslegung seiner Systeme hat. Dies ist in vielen Fllen ein entscheidendes Kriterium, zum Beispiel beim Einsatz von Applikationen fr Buchungs- oder Reservierungssysteme.
59
3.2.2
Die Verfgbarkeit von permanenten Verbindungen
Das Gleiche gilt fr die meisten Festverbindungen und anderen WAN-Services. In ihren Vertrgen garantieren die Provider entsprechende Verfgbarkeiten. Die fr Standardfestverbindungen eingesetzten Fernvermittlungssysteme der groen Carrier bieten Verfgbarkeiten hnlich der von ISDN, und auch die Frame-Relay- und ATM-Technologie ist mittlerweile mit so genanntem Carrier-grade-Equipment aufgebaut, das auch ein mittleres Erdbeben unbeschadet bersteht.
3.2.3
Die Verfgbarkeit von IP-VPNs
Diese Verfgbarkeiten muss ein virtuelles privates Netzwerk ebenfalls bieten knnen, soll es ein traditionell aufgebautes Netzwerk ergnzen oder gar ersetzen. Denn blicherweise investiert man nicht in eine Technologie, die qualitativ schlechter ist als die aktuelle. Es sei denn, die neue Technologie bietet enorme Kostenvorteile. Dann ist man schon eher geneigt, einen Kompromiss zu machen oder sich zu berlegen, welche Verfgbarkeit denn wirklich bentigt wird. Es gilt also, berhaupt erst einmal zu ermitteln, welche Verfgbarkeit tatschlich bentigt wird. In sehr vielen Fllen arbeiten Unternehmen beispielsweise mit Festverbindungen nicht wegen ihrer 99,99% Verfgbarkeit, sondern einfach, weil es zum Zeitpunkt der Entscheidung keine wirklich besseren Alternativen gab. Um die notwendige Mindestverfgbarkeit zu ermitteln, muss man sich Klarheit verschaffen, welche Applikationen in welchem Mae das VPN benutzen werden und welche Implikationen Verbindungsabbrche verursachen knnen. Es ist auch wichtig zu wissen, welcher Art der Datenverkehr ist und welches Zeitprofil er aufweist. Wird das VPN zum Beispiel nur whrend der Brostunden benutzt, z.B. fr Online-Anwendungen, kann man getrost eine nur halb so gute Verfgbarkeit akzeptieren, ohne eine Qualittseinbue zu haben. Statistisch gesehen fllt mehr als die Hlfte der Ausfallzeit in Zeiten, in denen das VPN ohnehin nicht benutzt wird. Die Verfgbarkeit eines Internet-VPN kann man nicht allgemein beurteilen. Man muss dabei drei Flle unterscheiden: 1. Die Verbindungen, auf denen das VPN basiert, gehen zu einem einzigen Provider. 2. Die Verbindungen, auf denen das VPN basiert, gehen zu zwei oder mehreren Providern, die miteinander kooperieren und entsprechende Durchleitungsvertrge und/oder Service Level Agreements (SLA) abgeschlossen haben. 3. Die Verbindungen, auf denen das VPN basiert, gehen zu verschiedenen Providern, die keine Vertrge miteinander abgeschlossen haben. Es ist nicht nachvollziehbar oder vorherbestimmbar, welchen Weg die Pakete nehmen und wie sie dort behandelt werden.
60
Performance
In den beiden ersten Fllen kann man mit dem oder den Service Providern geeignete Service Level Agreements abschlieen, in denen neben anderen Eckwerten auch die Mindestverfgbarkeitszeit vertraglich geregelt ist. Hier werden mittlerweile in den meisten Fllen bereits Verfgbarkeitszeiten garantiert, die deutlich ber denen der meisten lokalen Kundennetzwerke liegen. Im dritten Fall ist dies nicht mglich; man kann zwar mit jedem einzelnen Provider SLAs vereinbaren, diese gelten aber nur fr ihre eigenen Netze, und es ist keine durchgehende Verfgbarkeit garantiert. Letztendlich mndet das Ganze wieder in eine Kostenkalkulation: Kosten die theoretisch mglichen Ausflle mehr, als ich durch die neue VPN-Technologie einspare?
3.3
Performance
Mit geeigneten herkmmlichen WAN-Lsungen kann man die meisten Verbindungen mit einer garantierten, festen Bandbreite und kurzen Verzgerungszeiten betreiben.
3.3.1
Die Performance von Whlverbindungen
Eine Whlverbindung eines Remote-Access-Benutzers arbeitet, wenn er einem ISDN-B-Kanal benutzt, mit einer festen, garantierten, nicht schwankenden bertragungsbandbreite von 64 Kbit/s und unmerklichen Verzgerungszeiten. Modemverbindungen sind mit maximal 56 Kbit/s etwas langsamer und knnen bei schlechter Leitungsqualitt sogar mit langsameren Geschwindigkeiten arbeiten. Dies tun sie leider in der Praxis auch meistens: Die wenigsten haben schon einmal ein V.90-Modem mit 56 Kbit/s an einem ffentlichen Fernsprechnetz arbeiten sehen, meist pegelt sich die Geschwindigkeit zwischen 40 und 50 Kbit/s ein.
3.3.2
Die Performance von permanenten Verbindungen
Standardfestverbindungen Auch die Standardfestverbindungen, wie sie in Deutschland zum Beispiel von der Deutschen Telekom angeboten werden, bieten festgelegte, garantierte bertragungsraten mit minimalen Verzgerungen, keinem Jitter und einer sehr hohen Verfgbarkeit.
61
Frame Relay Bei Frame-Relay-Netzen kann man neben garantierten Mindestbandbreiten (CIR, Committed Information Rate) auch Spitzengeschwindigkeiten (CBR, Committed Burst Rate) vereinbaren, die meist der Geschwindigkeit der Zugangsleitungen entsprechen. So kann man sich zum Beispiel mit einer 64-Kbit/s-Standardfestverbindung auf das Frame-Relay-Netzwerk eines Providers aufschalten lassen und vereinbaren, dass jederzeit eine bertragung mit 24 Kbit/s garantiert ist dass man aber, falls es die Auslastung des Netzwerks zulsst, auch bis zur maximalen Leitungsgeschwindigkeit von 64 Kbit/s arbeiten kann. Die Kosten erhhen oder reduzieren sich durch die hohe Geschwindigkeit nicht, da bei Frame Relay volumenabhngig abgerechnet wird. ATM Fr ATM gelten die gleichen Kriterien wie auch fr Frame Relay, jedoch sind je nach Provider Geschwindigkeiten bis 155 Mbit/s mglich.
3.3.3
Die Performance von IP-VPNs
Bei all diesen Technologien hat man feste oder kalkulierbare Performancewerte, die ein VPN ebenfalls bieten muss, wenn es diese ablsen soll. Auch hier muss man sich beim konkreten Anforderungsprofil die gleichen Gedanken machen, die man sich auch bei der Frage der Verfgbarkeit gemacht hat. Was brauche ich wirklich? Wenn eine Standardfestverbindung von 64 Kbit/s durch VPN-Technologie ersetzt werden soll, kann man dies beispielsweise auf eine ganz einfache Weise tun, indem man mehrere Tage oder Wochen rund um die Uhr den Datenverkehr analysiert und daraus ein Verkehrsprofil erzeugt. Daraus leitet man seine tatschlichen Anforderungen hinsichtlich der bentigten Performance ab. Garantien ber Durchsatzwerte in Internet-VPNs kann man auch hier in einem Service Level Agreement mit einem oder mehreren Service Providern abschlieen. Das ist allerdings bis zu einem gewissen Mae Augenwischerei. Denn in Wirklichkeit wird nichts garantiert, das ist den meisten Providern technisch auch gar nicht mglich, sondern es wird festgelegt, was passiert (Vertragsstrafe), wenn die Bandbreite nachgewiesenermaen nicht zur Verfgung steht.
3.4
Quality-of-Service (QoS)
Bevor wir uns mit dem Thema Quality-of-Service (QoS) in IP-VPNs auseinander setzen, ist es sinnvoll, die QoS-Thematik selbst etwas eingehender zu beleuchten. Gerade in diesem Bereich, obwohl zur Zeit viel diskutiert, gibt es reichlich Begriffsverwirrung und vor allem auch eine Reihe von unterschiedlichen Konzepten zur Umsetzung des Gedankens.
62
Quality-of-Service wird manchmal als Manahme gegen eine zu kleine Bandbreite angesehen, aber auch das cleverste QoS-Konzept macht aus einer 64Kbit/s-Leitung keine 2-Mbit/s-Leitung. Was QoS in Wirklichkeit tut, ist, die zur Verfgung stehende Bandbreite ungerecht zu verteilen. Die Systematik, die hinter dieser gezielten Ungerechtigkeit steckt, ist das Thema des folgenden Abschnitts.
3.4.1
Einfhrung in QoS-Konzepte
Die verschiedenen Konzepte, um QoS in bertragungsnetzen einzufhren, resultieren aus den verschiedenen Applikationen, die solche Netze gleichzeitig benutzen, und aus der im Weitverkehrsbereich oft limitierten bertragungskapazitt. In lokalen Netzen ist es, im Vergleich zu Weitverkehrsnetzen, nicht so aufwendig, hohe Bandbreiten zur Verfgung zu stellen. In den letzten sechs Jahren hat sich die mittlere Bandbreite in Unternehmens-LANs etwa verhundertfacht, im WAN-Bereich ist solch ein Wachstum offensichtlich nicht zu beobachten. Aus einer 64-Kbit/s-Verbindung ist vielleicht eine 128-Kbit/soder 2-Mbit/s-Verbindung geworden, aber bestimmt keine 6,4-Mbit/s-Leitung. Andererseits operieren Unternehmen immer dezentraler, und die eingesetzten Applikationen werden immer hungriger nach Bandbreite. So fand zunehmend eine berbuchung der vorhandenen WAN-Bandbreiten statt, und man begann zu untersuchen, ob denn alle Datenpakete die gleiche Prioritt besitzen mssen und welche Anforderungen bestimmte Applikationen an die Netzwerkverbindung stellen. Denn das mittlerweile immer hufiger benutzte IP-Protokoll behandelt alle Pakete gleich, leitet sie weiter, so gut es geht (Best-Effort-Transport), und stellt somit ohne zustzliche Manahmen ein Problem dar, falls man den Datenverkehr differenzieren will. Qualittsparameter Welche Parameter bestimmen nun die Qualitt eines Datenflusses oder einer Verbindung? Es sind, neben der Bandbreite, vor allem drei Werte, die darber entscheiden, ob eine bestimmte Qualitt gegeben ist oder ob eine bertragung berhaupt erfolgreich ist: Verzgerungszeit (Delay) Variation der Verzgerungszeit (Jitter) Mittlere Fehlerrate Die Verzgerungszeit ist die Zeit, die vergeht, bis ein Datenpaket vom Sender zum Empfnger gelangt. Eine negative Beeinflussung dieses Wertes erfolgt blicherweise in Vermittlungssystemen.
63
Eine Variation der Verzgerungszeit, der so genannte Jitter, liegt dann vor, wenn die Verzgerungszeit kein fester Wert und damit vorherbestimmbar ist, sondern sich laufend ndert. Die mittlere Fehlerrate ist der Wert, der sich aus dem Verhltnis von korrekt bertragenen und zerstrten oder verlorenen Datenpaketen ergibt. Ein Paket gilt definitionsgem auch dann als verloren, wenn es aus Sicht einer Applikation zu spt ankommt. In Tabelle 3.1 sehen Sie, welche Anforderungen verschiedene Applikationen ihrer Natur gem an die verschiedenen Quality-ofService-Parameter stellen.
Variation der Verzgerung Niedrig Niedrig Mittel Hoch Hoch
Verzgerung E-Mail Dateibertragung (FTP) Videostrom (MPEG) Videokonferenz Telefonie Niedrig Niedrig Hoch Hoch Hoch
Fehlerrate Hoch (0 Fehler) Hoch (0 Fehler) Niedrig Niedrig Niedrig
Tab. 3.1: Die Prioritt der Anforderungen verschiedener Applikationen an die QoS
Zustzlich zu diesen Qualittsparametern ist die verfgbare Bandbreite ein Faktor, der einen indirekten Einfluss auf die Verbindungsqualitt hat. Die Bandbreite selbst wird in der Regel von der Physik bestimmt, also von elektrischen und optischen Parametern der Leitungen und von der Verarbeitungsgeschwindigkeit der Vermittlungssysteme. An diesem Wert kann meistens auch nichts verndert werden: Die Bits werden in einer Leitung in der Reihenfolge transportiert, in der sie eingeben wurden, und zwar mit der Geschwindigkeit bzw. dem Takt des Mediums. Eingreifen kann man aber in den Vermittlungssystemen, wenn man bestimmte Pakete oder bestimmte Datenflsse dort unterschiedlich behandelt. Qualittsanforderungen verschiedener Applikationen In Tabelle 3.1 haben Sie gesehen, dass unterschiedliche Arten von Anwendungen auch sehr unterschiedliche Anforderungen an die verschiedenen Qualittsparameter stellen. So muss die mittlere Fehlerrate bei einer Dateibertragung gleich 0 (Null) sein, denn sobald auch nur ein einziges Bit fehlerhaft ist, ist die bertragene Datei nicht mehr integer. Bei der Sprachkommunikation hingegen kann sogar das eine oder andere kleine Paket ganz verloren gehen, man ist ja von schlechten Telefonleitungen schon einmal das eine oder andere Knacken in der Leitung gewohnt von dem, was ein MobiltelefonBenutzer ber sich ergehen lassen muss, einmal ganz zu schweigen. Das Gleiche gilt auch fr Videobertragungen: Ein paar kleine schwarze Punkte
64
nimmt man in einem bewegten Bild subjektiv ohnehin nicht wahr. Was sich aber extrem schlecht auf solche Verbindungen auswirkt, sind groe Verzgerungszeiten bei interaktiver Sprach- oder Videokommunikation. Bei einem Mail-Transfer wiederum ist dieser Wert nicht so tragisch, denn ob die E-Mail nach zwei oder nach acht Sekunden ankommt, ndert an deren Qualitt berhaupt nichts. Welche Anstze gibt es nun, die fr bestimmte Applikationen erforderliche Qualitt einzuhalten? Vorherbestimmte Qualitt Ein Paradebeispiel hierfr ist eine Telefonverbindung, zum Beispiel ISDN. Hier wird fr die Dauer der Verbindung zwischen den beiden Gesprchspartnern ein Datenpfad mit einem Vielfachen der erforderlichen Bandbreite permanent durch das Netzwerk geschaltet. Die Verzgerung ist minimal, subjektiv garantiert nicht wahrnehmbar und konstant. Somit sind alle drei Qualittskriterien voll erfllt. Eine andere Idee ist es, das Transportnetz einfach so berzudimensionieren, dass die gesamte Bandbreite hher ist als die Summe der von allen Datenstrmen bentigten Bandbreiten. Somit haben auch im schlimmsten Fall alle Applikationen ihre bentigte Bandbreite, eine relativ kurze, vorherbestimmbare und feste Verzgerungszeit und keine berlastbedingten Fehlerraten. Allerdings hat dieses Konzept einen unschnen Nachteil, denn man schiet hierbei mit Kanonen auf Spatzen. Man stellt viel mehr Ressourcen zur Verfgung, als im Durchschnitt wirklich bentigt werden und diese mssen auch bezahlt werden. Flussbasierende Qualitt Hinter diesem Ansatz steht der Gedanke, eine Reihe von Netzwerkressourcen fr einen bestimmten Datenfluss zu reservieren. Dieser Datenfluss kann zum Beispiel eine Verbindung zwischen Netzen, Rechnern oder Applikationen sein. Eine Voraussetzung dafr, dass dies funktioniert, ist sowohl ein Signalisierungsprotokoll als auch die Notwendigkeit, dass alle beteiligten Systeme vor allem auch alle Vermittlungssysteme diese Technologie implementiert haben. Sobald ein Datenfluss beginnen soll, erfolgt durch das Signalisierungsprotokoll eine sukzessive Signalisierung an alle beteiligten Systeme, mit der Aufforderung, die entsprechenden Ressourcen fr diesen Datenfluss zur Verfgung zu stellen und zu reservieren. Wenn dies erfolgreich war, also alle positiven Rckmeldungen erfolgten, dann kann die bertragung beginnen. Allerdings ist dieses Konzept mit einigen Problemen behaftet, insbesondere dem der mangelnden Skalierbarkeit in groen Netzen wie etwa dem Internet. In kleineren Netzen oder bei langer Lebensdauer der Datenflsse ist dies kein Problem, aber die meisten bertragungen im Internet haben nur eine kurze
65
Lebensdauer. Die Folge ist die, dass die permanent notwendige Signalisierung sowie die Reservierung und Freigabe bestimmter Ressourcen und deren Verwaltung bei Hunderttausenden oder Millionen von Datenflssen auf einem Internet-Router nicht praktikabel sind. Es wurden bisher in den RFCs 2211, 2212 und 2205 hinsichtlich der flussbasierenden Qualitt verschiedene Standardisierungsbemhungen unternommen, jedoch setzen sie sich in groen Netzen wie dem Internet nicht durch, da die notwendigen Ressourcen, insbesondere fr das Resource Reservation Protocol (RSVP) auf den Internet-Routern zu gro sind. Klassenbasierende Qualitt Ein anderer Ansatz, der dieses Problem umgehen soll, ist die so genannte klassenbasierende Qualitt oder Class-of-Service (CoS). Die zu bertragenden Netzwerkpakete werden in bestimmte, wohl bekannte Klassen eingeteilt und im Paket-Header entsprechend markiert. Die an diesem Konzept beteiligten Vermittlungssysteme kennen entsprechende Strategien, wie Pakete einer bestimmten Klasse zu behandeln sind. Abhngig von der Art der Vermittlungssysteme (ATM, Frame Relay, LAN-Switch usw.), werden diese Klassenparameter in geeigneter Weise auf die jeweilige Technologie angewendet. Hier ist keine Signalisierung mehr notwendig, denn die fr die Verarbeitung bentigten Ressourcen kennt das Vermittlungssystem bereits. Pakete verschiedener Quellen oder Applikationen werden, falls sie der gleichen Klasse angehren, innerhalb ihrer Klasse nach dem Best-Effort-Prinzip transportiert. Aber auch dieses verbindungslose Prinzip weist einige Nachteile auf. Denn ohne eine Signalisierung ist fr den Sender oder bestimmte Vermittlungssysteme nicht erkennbar, ob die erforderlichen Ressourcen fr die bentigte Service-Klasse auf allen beteiligten Systemen berhaupt verfgbar sind. Ein weiteres Problem kann entstehen, wenn verschiedene Netzwerke und das Internet ist ein Konglomerat aus verschiedenen Netzen verschiedene Service-Klassen definiert haben. Hier kann es im Extremfall dazu kommen, dass sich die Pakete nach dem Durchlaufen verschiedener Netze bei konservativer Umsetzung (im Zweifelsfall in die nchsthhere Klasse) der CoS-Markierungen am Ende in der hchsten Service-Klasse wiederfinden. Hchste Service-Klasse klingt zwar gut, bedeutet aber in letzter Konsequenz tatschlich einen Best-Effort-Transport der Pakete, da diese sich alle in einer einzigen Klasse drngeln.
3.4.2
Quality-of-Service bei Whlverbindungen
Die kritischen Qualittsparameter bei Whlverbindungen hngen vom verwendeten Medium ab, also davon, ob man ISDN, analoge Telefonie oder Mobilfunk benutzt.
66
Im Fall von ISDN liegen alle Werte im grnen Bereich, die mittlere Fehlerrate ist praktisch null, die Verzgerung ist minimal, und es gibt keinen Jitter. Darber hinaus ist die Bandbreite ebenfalls garantiert. Analoge Verbindungen sind ebenfalls fast verzgerungsfrei, die mittlere Fehlerrate ist aus Sicht der hheren Protokolle ebenfalls null. Mobilfunkverbindungen sind aus Datenbertragungssicht katastrophal, denn was dem menschlichen Gehirn an Verarbeitungsleistung abverlangt wird, um den gesprochenen und whrend der bertragung oft verstmmelten Text zu entschlsseln, das leisten Protokolle wie IP im Datenbereich nicht. Hier mssen entsprechende hhere Protokolle unter Umstnden den Paketverlust ausgleichen, und die bertragung ist insgesamt nicht sehr effizient.
3.4.3
Quality-of-Service bei permanenten Verbindungen
Standardfestverbindungen Die kritischen Qualittsparameter bei Standardfestverbindungen sind alle sehr gut, die mittlere Fehlerrate ist praktisch null, es gibt keinen Jitter, und die Verzgerung kann insgesamt vernachlssigt werden. Darber hinaus ist die Bandbreite ebenfalls garantiert. ATM ATM wurde, wie Sie vermutlich wissen, primr zum Transport von Sprache und Video entwickelt, aber auch zum Transport anderer Daten. Aus diesem Grund wurde von Anfang an auch auf das Thema Quality-of-Service geachtet. Die Technik wurde auf hohe Geschwindigkeit und geringe Verzgerungen getrimmt. ATM definiert fnf unterschiedliche Service-Klassen, die in Tabelle 3.2 beschrieben sind. Diese unterschiedlichen Klassen sind fr verschiedene Arten von Applikationen wie Video, interaktive Sprachbertragung (Telefonie) oder Datenpaketbertragung geeignet.
Kategorie Constant Bit Rate (CBR) Non-real-time VBR (Nrt-VBR) Available Bit Rate (AVB) Unspecified Bit Rate (UBR) ATM-Parameter PCR, CTD, CDV, CLR PCR, SCR, CLR PCR, MCR (keine) Applikationstyp Telefonie, Sprache Frame Relay over ATM Daten (IP, IPX) Daten (IP, IPX)
Real-time Variable Bit Rate (rtVBR) PCR, CTD, CDV, CLR, SCR Sprache/Video (Paket)
Tab. 3.2: Die fnf ATM-Service-Klassen
67
In ATM definieren die folgenden sechs verschiedenen Parameter die fnf Service-Klassen: Peak Cell Rate (PCR), die maximal mgliche Rate, mit der ATM-Zellen bertragen werden knnen Cell Delay Variation (CDV), die Abweichung der Verzgerung zweier beliebiger ATM-Zellen Cell Loss Ratio (CLR), das Verhltnis von fehlerfreien zu fehlerhaft bertragenen oder verworfenen Zellen Sustainable Cell Rate (SCR), der mittlere, erreichbare Durchsatz Minimum Cell Rate (MCR), die minimale Zellbertragungsrate Obwohl ATM zwischen verschiedenen ATM-Switches kleine Zellen bertrgt, ist es verbindungsorientiert und basiert auf virtuellen Verbindungen (VC, Virtual Circuit). Es werden entweder feste virtuelle Verbindungen (PVC, Permanent Virtual Circuit) durch ein ATM-Netz konfiguriert, oder sie werden fr die Dauer einer Verbindung geschaltet (SVC, Switched Virtual Circuit) und anschlieend wieder deaktiviert. Im Internet, in dem ATM vor allem in den Backbones der Service Provider und Carrier eingesetzt wird, werden vor allem PVCs eingesetzt. ATM bietet die Mglichkeit, die Konfiguration eines ATM-Netzwerks zu vereinfachen, indem man verschiedene VCs zu einem virtuellen Pfad (Virtual Path, VP) zusammenfasst. Frame Relay Frame Relay bietet ebenfalls die Mglichkeit, verschiedene Service-Klassen zur Verfgung zu stellen. Diese unterscheiden sich hauptschlich durch die zugesicherte Bitbertragungsrate (CIR, Committed Information Rate) und die maximal mgliche bertragungsrate (EIR, Excess Information Rate). hnlich wie ATM ist Frame Relay verbindungsorientiert und transportiert seine Daten in kleinen Paketen (Frames). Auch hier gibt es permanente (PVC) und geschaltete (SVC) virtuelle Verbindungen. Aufgrund seiner Architektur und seiner Ausrichtung auf die Datenbertragung ist nicht so gut fr Sprachoder Videobertragungen geeignet und wird nicht fr Geschwindigkeiten ber 45 Mbit/s eingesetzt. ATM und Frame Relay sind im Augenblick die einzige Mglichkeit, mit der die Service Provider den Kunden eine Quality-of-Service anbieten knnen. Der Provider stellt fr jede Verbindung einen entsprechenden PVC mit den geeigneten Serviceparametern zur Verfgung. Allerdings existieren in einem groen Netz auf diese Art und Weise sehr viele PVCs, denn wenn ein Kunde beispielsweise zehn Niederlassungen sternfrmig vernetzen will, muss der Service Provider N x (N-1) = 10 x 9 = 90 PVCs konfigurieren.
68
3.4.4
Quality-of-Service im IP-Protokoll
Das Internet-Protokoll wurde ursprnglich als verbindungsloses Verfahren zum asynchronen Transport von Datenpaketen entwickelt. Es garantiert keine Paketzustellung oder bestimmte Zeiten, in denen ein Paket bertragen wird. Die Vermittlungssysteme (Router) verarbeiten die Pakete in der Reihenfolge, in der sie eintreffen, und machen sich keine Gedanken ber deren Wichtigkeit oder die mit den Paketen verknpfte Anwendung. Falls auf einem schnellen Medium wie Ethernet mehr Pakete in einem Router ankommen, als dieser auf einem langsameren Interface ausgeben kann, kommt es zu Verzgerungen oder im schlimmsten Fall zu Paketverlusten. Dieses Verhalten ist kennzeichnend fr IP und das Internet. Dies war lange Zeit auch kein Problem, da ber dieses Netz in den Anfngen meist nur E-Mail, FTP und Telnet betrieben wurden alles Applikationen, die sehr gutmtig auf durch Bandbreitenengpsse bedingte Verzgerungen reagieren. Auch das World Wide Web mit seinem grafischen Interface war zunchst an die Bedingungen im Internet angepasst. Da aber zunehmend Applikationen, die auf den LAN-Betrieb zugeschnitten sind und Anwendungen wie Voice- oder Video-ber-IP eingesetzt werden, ist das Best-Effort-Prinzip von IP nicht mehr adquat. Und genau hier liegt auch das Problem von IP, denn im Gegensatz zu ATM oder Frame Relay, die von vornherein fr die Mglichkeit, Quality-of-Service zu bieten, entwickelt wurden, war dies nie die Idee von IP, und man hatte auch nichts dafr vorgesehen. Nichts ist allerdings nicht ganz richtig. Es gibt doch ein Byte im IP-Header, das viele Jahre ziemlich stiefmtterlich behandelt und von den meisten Systemen schlicht ignoriert wurde: Das Type-of-Service-Byte (TOS-Byte), das eigentlich fr Quality-of-Service-Zwecke gedacht war. Dieses in der Vergangenheit sehr vernachlssigte Feld im IP-Header erlebt zur Zeit eine Renaissance, verbunden mit seiner Umbenennung, denn es heit jetzt DSCP (Differentiated Services Code Point) und dient dazu, die Zugehrigkeit eines Pakets zu einer bestimmten Service-Klasse anzuzeigen.
3.4.5
Die IP-Differentiated-Services-Architektur (DiffServ)
DiffServ ist eine klassenbasierende Architektur (RFC2475) fr die Dienstqualitt in IP. Ihr werden aufgrund ihrer hohen Skalierbarkeit die besten Chancen als dominierendes Verfahren eingerumt. Die Grundidee ist, dass die IPPakete beim Eintritt in ein Netzwerk einer bestimmten Klasse zugeordnet und entsprechend markiert werden. Die Vermittlungssysteme eines DiffServ-Netzwerks werten die Markierungen aus und behandeln die Pakete entsprechend. Die Systeme kennen also nur Service-Klassen und unterscheiden weder bestimmte Datenflsse noch Adressen. Sie sind fr jede Service-Klasse auf ein bestimmtes Verhalten (PHB, Per Hop Behaviour) konfiguriert, das heit sie lei-
69
ten eingehende Pakete in entsprechende Warteschlangen verschiedener Prioritt oder verwerfen sie unter bestimmten Umstnden (z.B. berlast) auch. DiffServ verlegt die Komplexitt der Klassifizierung des Datenverkehrs auf die Grenzen des Netzwerks. Diese Systeme mssen die zu bertragenden Datenpakete beim Eintritt in das Netz klassifizieren, markieren und bereits ihrer Service-Klasse entsprechend behandeln. Die Router im Netzwerk mssen die Entscheidung, wie ein Paket zu behandeln ist, lediglich aufgrund des DSCP-Felds im IP-Header treffen. Es erfolgt weder eine Signalisierung zwischen den Routern noch mssen die Zustnde einer Vielzahl verschiedener Datenflsse verwaltet werden. Viele dieser Router haben bereits Mechanismen und Ressourcen zur Paket-Priorisierung implementiert, so dass eine Erweiterung auf die DiffServ-Architektur nur ein logischer Schritt ist, der meist keine teuren Erweiterungen der Systeme nach sich zieht. Die Architektur von DiffServ legt fest, dass die Klassifizierung und Markierung der Pakete in einem so genannten Edge-Router erfolgt, also einem Router an der Grenze eines Netzwerks. Endsysteme oder Applikationen mssen diese Architektur nicht untersttzen, knnen dies aber und tun es auch zunehmend. Wo die Klassifizierung und Markierung letztendlich stattfindet, ist daher unterschiedlich und hngt neben der Qualittsstrategie des Netzwerks auch von den verschiedenen beteiligten Komponenten, also Applikationen, Betriebssystemen und Netzwerksystemen, ab. Es kann sowohl eine Klassifizierung in den Endsystemen stattfinden, z.B. durch Applikationen, oder dies kann auch auf dedizierten Netzwerkkomponenten nach entsprechenden Regeln (Policies) erfolgen. Diese Regeln knnen zentral festgelegt und verwaltet und dann auf die beteiligten Systemkomponenten verteilt werden. Es kann auch ntig sein, durch geeignete Policies bestimmte Klassifizierungen an Netzwerkgrenzen zu ndern, da unter Umstnden in Endgerten Markierungen durch Applikationen oder Benutzer vorgenommen wurden, die nicht mit der netzwerkweiten QoS-Strategie konform sind. DiffServ ist ein Protokoll in der Schicht 3, also der Netzwerkschicht. Dadurch, dass es somit unabhngig von Layer-2-Protokollen (wie Frame Relay oder ATM) ist, kann es mit einer Vielzahl von Infrastrukturen genutzt werden. Die Router oder Switches mssen natrlich entsprechend konfiguriert werden, um die entsprechende Service-Klasse korrekt zu behandeln, also muss beispielsweise festgelegt werden, welche ATM-Service-Parameter wie zu konfigurieren sind. Aber dies erfolgt nur in eine Richtung: aus der Sicht des Schichtenmodells von oben nach unten, und es findet keine Wechselwirkung in der Art statt, dass Layer-2-Spezifika die Service-Klasse beeinflussen. Dies ist ein weiterer wichtiger Pluspunkt zugunsten des DiffServ-Modells, denn sehr viele grere Netze benutzen zum Transport von IP-Paketen eine Vielzahl verschiedener Infrastrukturen (ATM, IEEE802.1q, Frame Relay usw.), die unterschiedliche Quality-of-Service- und Priorisierungsmechanismen bieten.
70
Diese knnen den DSCP auswerten, ihn aber nicht ndern, so dass die Klasseninformation whrend der vollstndigen bertragung erhalten bleibt.
0 1 2 3 4 5 6 7
101110xx = Expedited Forwarding Code Point (RFC2598) 00000000 = Best Effort Forwarding Code Point 11x000xx = Network Control Traffic Code Point
Reserved
Drop Precedence
Class Selector
Assured Forwarding Code Points (RFC2597) Class 1 Low Drop Precedence Medium Drop Precedence High Drop Precedence 001010 001100 001110 Class 2 010010 010100 010110 Class 3 C 011010 011100 011110 lass 4 100010 100100 100110
Class Selector Code Points (RFC2474) Class 0 000000 Class 1 001000 Class 2 010000 Class 3 011000 Class 4 100000 Class 5 101000 Class 6 Class 7 110000 111000
Abbildung 3.3: Der Differentiated Services Code Point (DSCP) im IP-Header
Die DiffServ-Service-Klassen Zur Zeit sind in DiffServ drei verschiedene Service-Klassen festgelegt: Premium Tiered Best Effort Zu jeder dieser Klassen gibt es ein festgelegtes Per Hop Behaviour (PHB), das in den Routern oder Switches eines DiffServ-Netzwerks untersttzt werden muss. Das PHB unterscheidet zwischen unmittelbarem Weiterleiten (EF, Expedited forward), garantiertem Weiterleiten (AF, Assured forward) und normalem Weiterleiten (DF, Default forward) der IP-Pakete. Wie das die verschiedenen Systeme technisch realisieren, ist nicht im Standard festgelegt.
71
Fr den so genannten Premium-Service muss jeder Router permanent einen gewissen Teil seiner Ressourcen reservieren, unabhngig von seiner tatschlichen Auslastung. Fr den Tiered-Service gilt das Gleiche, jedoch werden diese Ressourcen in verschiedene Priorittsstufen untergliedert. Was an Ressourcen brig bleibt, wird vom Best-Effort-Service benutzt. In Abbildung 3.3 sehen Sie den Aufbau des DSCP-Felds im IP-Header. DiffServ benutzt derzeit, wie im RFC2474 festgelegt, die ersten sechs Bits davon. Davon legen die ersten drei Bits die Klasse fest, und die folgenden drei Bits geben die Vorrangigkeit innerhalb der jeweiligen Klasse an, mit der Pakete in berlastsituationen verworfen werden knnen. Der Codepunkt 101110 markiert den Premium-Service und der Codepunkt 000000 den Best-Effort-Service. Der DiffServ-Edge-Router Der Klassifizierer ist die Funktion, die in einem so genannten Edge-Router ein eingehendes Paket daraufhin prft, welche Bits im DSCP-Feld zur Klassifizierung des Pakets gesetzt werden mssen. Er teilt die IP-Pakete somit in verschiedene Klassen ein, die der Betreiber des Transportnetzwerks untersttzt. Nach welchen Kriterien eine solche Klassifizierung erfolgt, richtet sich entweder nach dem Service-Level-Agreement (SLA), das mit dem Provider abgeschlossen wurde, und/oder nach der Qualittsstrategie des Netzwerks. Die Entscheidung des Klassifizierers erfolgt zum Beispiel aufgrund von Quelloder Zieladressen, Port- oder Protokollnummern oder aufgrund des DSCPFelds. Denn es kann durchaus sein, dass ein Paket verschiedene Netze unterschiedlicher Provider durchluft oder dass in einem Kundennetz bereits schon eine DiffServ-Klassifizierung erfolgt ist. Zur Zeit erfolgt die Markierung statisch nach fest im Edge-Router vorgegebenen Regeln. Anschlieend wird das markierte Paket seiner Markierung entsprechend in den passenden Ausgangspuffer geschrieben und von dort in das Transportnetz weitergeleitet. In Abbildung 3.4 sehen Sie in dem Edge-Router neben dem Markierer und dem Klassifizierer noch einen so genannten Shaper. Dieses Modul sorgt dafr, dass der Datenverkehr in das Transportnetz einen bestimmten vereinbarten Wert oder die mgliche Bandbreite einer Verbindung nicht berschreitet. Der DiffServ-PHB-Router Der PHB-Router braucht sich keine Gedanken mehr ber die Klassifizierung oder Markierung eines Pakets zu machen, er muss es nur aufgrund der Eintrge im DSCP-Feld verarbeiten und in die korrekte Warteschlange stellen. In Abbildung 3.5 knnen Sie erkennen, dass der PHB-Router eine Teilmenge der Funktionen des Edge-Routers aufweist und somit viel weniger belastet wird. Die Verarbeitung ist demzufolge relativ schnell, denn es muss nur das DSCPFeld ausgewertet werden. Da das PHB fr die EF-Klasse bedingt, dass ein jitterfreies, schnelles Weiterleiten der Pakete garantiert ist, muss der Provider umfangreiche Manahmen treffen, um dies zu erreichen und dies verur-
72
sacht natrlich entsprechende Kosten. Zuknftige Modelle, die auf dem Einsatz so genannter dynamischer Policy-Server basieren, ermglichen eine dynamische Zuteilung von Ressourcen fr die EF-Klasse aufgrund der aktuellen Netzlast und befreien den Provider damit von der statischen Reservierung der notwendigen Betriebsmittel.
Policy-ServerInterface
Management-Interface
Policy
Classifier
Marker
DSCP
PriorityQueues
InputInterface
Packet Distributor
OutputInterface
Shaper/ Scheduler
Abbildung 3.4: Der DiffServ-Edge-Router klassifiziert und markiert die IP-Pakete.
Policy-ServerInterface
Management-Interface
PriorityQueues
InputInterface
Packet Distributor
OutputInterface
Shaper/ Scheduler
Abbildung 3.5: Der DiffServ-PHB-Router verarbeitet die IP-Pakete anhand des DSCP-Feldes.
73
3.4.6
Differentiated Services in IP-VPNs
Hier mssen zwei unterschiedliche Szenarien betrachtet werden: Setzt der Kunde in seinem Netzwerk bereits DiffServ ein und mchte er, dass der Provider die Pakete entsprechend behandelt, oder soll eine entsprechende Klassifizierung der IP-Pakete erst beim Eintritt in das Provider-Netzwerk erfolgen? Im ersten Fall muss eine Vereinbarung zwischen Kunde und Provider darber geschlossen werden, wie die Entsprechung der Service-Klassen des Kunden und den mit ziemlicher Sicherheit unterschiedlichen Service-Klassen des Providers auszusehen hat. Weiterhin muss dafr Sorge getragen werden, dass die DSCP-Informationen beim Einkapseln des Pakets durch ein Tunnelingprotokoll nicht verloren gehen. In IP-VPNs benutzt man meist das IPSec-Protokoll, das genau dies tut: Es kopiert den Inhalt des DSCP-Felds bei ausgehenden Paketen in den neu erzeugten IP-Header und macht es damit fr den Provider verfgbar. Beim Entkapseln des IP-Pakets auf der Empfngerseite wird das DSCP-Feld im ueren Header verworfen. Dadurch ergibt sich auch die Mglichkeit fr den Service Provider, das DSCP-Feld des IPSec-Pakets beim Eintritt in sein Netzwerk zu ndern, also eine neue Klassifizierung vorzunehmen, ohne dass das originale DSCP-Feld davon betroffen ist. Bei den Layer-2Tunneling-Protokollen fehlt diese Funktionalitt zurzeit. Im zweiten Fall ist das Problem, je nach Reihenfolge der Verarbeitungsschritte und der Systeme mglicherweise berhaupt nicht lsbar. Nehmen wir einmal den heute blichen Fall, ein Internet-VPN mit dem IPSec-Protokoll im Tunnelmodus aufzubauen. In diesem Fall wird das originale IP-Paket vollstndig verschlsselt und in ein anderes IP-Paket eingekapselt. Dies erfolgt meist in einem IPSec-Gateway des Kunden. Das IPSec-Paket wird nun zum Router des Service Providers geschickt, der eine Klassifizierung vornehmen soll. Nur wonach? Alle dafr notwendigen Parameter wie originale IP-Adressen, Portund Protokollnummern usw. sind verschlsselt. Einzig die ueren IP-Adressen sind noch erkennbar, aber diese ermglichen nur eine Priorisierung nach Quell- und Absenderstandort etwas, was normalerweise nicht zur Paketklassifizierung benutzt wird. Mgliche Auswege sehen zum Beispiel so aus, dass die IPSec-Funktionalitt erst nach der Klassifizierung im Edge-Router des Providers greift oder dass das VPN-Gateway des Kunden bereits eine Klassifizierung vornimmt, die nach den Angaben des Service Providers konfiguriert wurde. In diesem Fall muss das IPSec-Gateway die Funktionalitt eines Edge-Routers bieten.
74
Skalierbarkeit und Migrationsfhigkeit
3.5
Skalierbarkeit und Migrationsfhigkeit
Wenn Sie heute ber den Einsatz eines VPN nachdenken, dann sollten Sie auch bereits an bermorgen denken. Langfristige Voraussagen sind aber ziemlich schwierig und treffen manchmal auch nicht zu, also strebt man eine mglichst hohe Offenheit seines Systems an Offenheit sowohl in Hinblick auf die Einhaltung von Standards, um gegebenenfalls einen Hersteller wechseln zu knnen, als auch in Hinblick auf die Modularitt und Erweiterbarkeit der Systemkomponenten. Think big start small Mit diesem Leitsatz liegt man genau richtig, denn fr VPNs gelten die gleichen Mastbe hinsichtlich Skalierbarkeit und Migrationsfhigkeit wie fr andere Netzwerktechnologien auch. Whrend der Planungsphase sollte man sich bereits Gedanken machen, wie das Netz in der Zukunft aussehen kann. Denn sehr viele Rahmenbedingungen sind stetiger nderung unterworfen, wie zum Beispiel die Zahl der Benutzer, bentigte Bandbreiten und Qualittsmerkmale durch neue Applikationen, rechtliche Gesichtspunkte und neue Geschftsfelder oder Akquisitionen. Beim Thema Skalierbarkeit muss man aber unbedingt zwischen Leistung und Sicherheit differenzieren. Denn die Sicherheitsstrategie eines Unternehmens richtet sich nach vllig anderen Kriterien. Ein VPN-Gateway in einem kleinen Zweigbro bentigt beispielsweise keinen so hohen Datendurchsatz wie seine Gegenstelle in der Unternehmenszentrale, auf der Hunderte von Verbindungen konzentriert werden, jedoch muss es den gleichen Sicherheitsanforderungen gengen. Hier gilt es sehr genau zu prfen, ob Endgerte fr kleine Auenstellen, die vom Systemdesign her fr eine kleine bertragungsbandbreite ausgelegt sind, diese auch dann noch bieten, wenn eine starke Verschlsselung eingesetzt wird. Ein Faktor, der sich in den meisten Netzwerken laufend ndert, ist die steigende Zahl von mobilen Anwendern und Heimbros. Hier sollte, wie es sich in der Praxis gezeigt hat, von vornherein mit einer entsprechend groen Zahl kalkuliert werden. Die Skalierbarkeit im Bereich der Systemleistung ist ein ganz wesentliches Entscheidungskriterium bei der Planung eines VPN. Meist sind Standorte verschiedener Gre, Heimbros und mobile Mitarbeiter mit der notwendigen Technologie auszustatten. Je nach Einsatzgebiet sind unterschiedliche Datendurchstze und Anschlusstechnologien notwendig, vom redundanten VPN-Konzentrator bis hinunter zur VPN-Clientsoftware fr PCs. Idealerweise sollen diese verschiedenen VPN-Systeme aber auch eine mglichst einheitliche Konfigurations- und Managementoberflche bieten.
75
3.6
Integration in existierende Netze
Selten bekommt ein Netzwerkplaner die Gelegenheit, ein VPN auf der grnen Wiese zu planen. Er hat viel hufiger die Aufgabe, dass ein VPN in bestehende Infrastrukturen zu integrieren. Diese Infrastrukturen sind bestehende lokale Netze, Weitverkehrsnetze und Remote-Dienste sowie die dazugehrigen Management-, Accounting- und berwachungssysteme. Das zunehmende Verlangen vieler Unternehmen nach Kostentransparenz auch im Netzwerkbereich fhrt zu nutzer- oder kostenstellenbezogenen Abrechnungssystemen, die vor allem in Verbindung mit WAN- und Remote-Access-Diensten eingesetzt werden, da diese durch die zustzlich an die Carrier zu entrichtenden Gebhren sehr kostenintensiv sind.
3.6.1
Management
Insbesondere sind bei der Integration der VPN-Komponenten die bereits vorhandenen Managementsysteme zur Konfiguration und berwachung zu untersttzen, die auch zu diesem Zweck fr traditionelles Netzwerkequipment eingesetzt werden. Die wichtigsten Funktionalitten sind die zur Konfiguration, zur berwachung und zur Abrechung der Netzwerkdienste. Konfiguration Die Konfiguration von Netzwerkkomponenten erfolgt mittlerweile fast ausschlielich ber SNMP (Simple Network Management Protocol, eine Menge von Funktionen zum Konfigurieren und berwachen von Netzwerkgerten und einem bertragungsprotokoll hierfr). Dieses Protokoll wurde entwickelt, um eine problemlose Interoperabilitt zwischen Netzwerkmanagementprodukten unterschiedlicher Hersteller zu ermglichen. Eine Netzwerkmanagementstation, meist eine Grafikworkstation, dient als zentrales Element zur Steuerung und berwachung, whrend auf den Netzwerkkomponenten selbst so genannte SNMP-Agents residieren. Diese Agents kommunizieren ber das Netzwerk mit der Managementstation, um Konfigurationsparameter zu setzen oder abzufragen. Eine weitere wichtige Funktionalitt der Agents ist ihre Fhigkeit, bei kritischen Zustnden auf dem Netzwerkgert einen so genannten SNMP-Trap zu erzeugen, der unmittelbar zur Managementstation geschickt wird, um diese ber das aufgetretene Problem zu informieren. Die Kommunikation der verschiedenen SNM-Komponenten erfolgt ber UDP-Pakete, in denen verschiedene Kommandotypen zum Setzen und Lesen von MIB-Objekten oder -Variablen eingekapselt werden. Eine MIB (Management Information Base) ist eine Datenstruktur, die die Summe aller managebaren Objekte der Netzwerkkomponenten darstellt. Leider ist die Sicherheit,
76
wenn man es berhaupt so nennen kann, von SNMP auf einem nicht allzu hohen Stand, so dass die Kommunikation mit einfachsten Methoden aufgezeichnet oder unbefugt verndert werden kann. Aus diesem Grund werden sicherheitskritische Systeme im Allgemeinen nicht ber SNMP konfiguriert. Auch die berwachung mit SNMP beschrnkt man auf nicht sicherheitskritische Parameter, wie Zhler fr bertragene Bytes oder Prfsummenfehler und hnliches.
Intranet
VPN-Konzentrator
SNMP-Traps
NetzwerkManagement station
Internet
webbasiertes Management
Syslog
Webbrowser
SyslogServer
Abbildung 3.6: Ein VPN-System muss mehrere Managementprotokolle untersttzen.
Bei sicherheitskritischen Netzwerkkomponenten benutzt man andere Protokolle zu deren Konfiguration. Neben herstellerspezifischen, oft nicht offen gelegten Protokollen haben sich hier das SSL-Protokoll (Secure Socket Layer) und IP Security (IPSec) durchgesetzt. Diese Protokolle sind standardisiert und mittlerweile weit verbreitet. Die Anforderungen an das Management, die aus dem hier Gesagten resultieren, sind genau genommen ein Kompromiss aus dem Wunsch nach reibungsloser Integration in bestehende SNMP-basierende Managementsysteme und der Forderung nach ausreichender Sicherheit. Es kann also auf einem VPNGert durchaus SNMP untersttzt werden, jedoch mit der Einschrnkung, dass die Konfiguration des Gerts abweichend vom Protokoll auf keinen Fall mit SNMP-Set-Befehlen durchgefhrt werden darf, sondern ber ein sicheres Protokoll erfolgen muss. In letzter Zeit hat sich das so genannte Web-based-Management immer weiter verbreitet. Hierbei greift man ber einen Webbrowser direkt auf die Netzwerkgerte zu, um sie zu konfigurieren oder abzufragen. Der Vorteil dieser
77
Methode besteht darin, mit dem Webbrowser eine grafische Benutzeroberflche zu haben, mit der mittlerweile fast jeder umgehen kann und die praktisch auf jedem Arbeitsplatzrechner installiert ist. Ein weiterer Pluspunkt ist, dass neue Funktionen auf dem Gert auch gleich in der grafischen Oberflche verfgbar sind. In traditionellen SNMP-Umgebungen mit speziellen Netzwerkmanagement-Applikationen mssen die Funktionen dem Programm erst bekannt macht werden, bevor man sie benutzen kann. Vor allem mit grafischen Darstellungen, insbesondere in heterogenen Umgebungen, tun sich leider die meisten SNMP-Managementsysteme und die Gertehersteller etwas schwer. Das Web-Management kann auch in Teilen kompatibel zu SNMP sein, indem der Browser intern die MIB dieses Gerts modifiziert oder abfragt und indem SNMP-Traps verwendet werden, um Alarmierungen abzusetzen. Allerdings ist das HTTP (Hyper Text Transfer Protocol), genau wie SNMP, alles andere als sicher: Man kann es relativ problemlos mitlesen oder verndern. Die Lsung dieses Sicherheitsproblems ist auch hier die Verwendung des SSL-Protokolls, das speziell zur sicheren Browser-Server-Kommunikation entwickelt wurde, oder noch sicherer der Einsatz von IPSec. Bei Einsatz und Kombination der richtigen, sicheren bertragungsprotokolle steht also einem zeitgemen webbasierten Management der VPN-Komponenten nichts mehr im Wege. berwachung Auch fr die berwachung von traditionellen Netzwerkkomponenten hat sich neben dem SNMP-Protokoll zunehmend das webbasierte Management durchgesetzt. Unter berwachung versteht man in diesem Zusammenhang die gezielte, durch eine Managementstation oder einen Browser ausgelste Abfrage von Systemparametern und das Versenden so genannter Traps, die von einem Netzwerksystem aufgrund eines kritischen Systemzustands ausgelst wurden. Das gezielte Abfragen von MIB-Variablen in den Netzwerkkomponenten muss sowohl durch SNMP-Get-Befehle als auch durch einen Browser untersttzt werden. Auch hier gilt es Vorsicht walten zu lassen, falls man damit auch sicherheitsrelevante Parameter abfragt, denn jedermann, der Zugriff auf die Netzwerkverbindung zwischen VPN-Komponente und Managementstation hat, kann SNMP und HTTP mitlesen! Der Einsatz von sicheren bertragungsprotokollen ist auch hier dringend angeraten. Die Erzeugung von SNMP-Traps zur Signalisierung von Alarmzustnden muss in jedem Fall untersttzt werden. Hier werden keine sicherheitsrelevanten Parameter ungeschtzt bertragen. Es wird lediglich der Managementstation mitgeteilt, welches Problem wo aufgetreten ist. Spezielle sichere bertragungsprotokolle sind hierfr nicht notwendig.
78
Aber ein anderer Punkt verdient in diesem Zusammenhang Beachtung: SNMP definiert im Standard nur eine kleine Anzahl von Traps. Will man aber Traps erzeugen, die bei Eindringversuchen in das Netzwerk oder bei anderen einsatzspezifischen Vorfllen oder Situationen generiert werden, muss das VPN-System eine derart erweiterte SNMP-Funktionalitt bieten. Generell sollte es mglich sein, fr alle kritischen Zustnde und damit sind nicht nur Hardwareprobleme gemeint die Generierung eines Traps konfigurieren zu knnen. Accounting Whrend in lokalen Netzwerken das Accounting, also die auf Benutzer, Organisationseinheiten oder Kostenstellen heruntergebrochene Abrechnung von Netzwerkdiensten, fast niemals eingesetzt wird, ist dies im WAN-Bereich immer fter und beim Remote Access fast immer zu finden. Dies hat eine Reihe von Grnden. Im LAN-Bereich fallen keine zustzlichen bertragungskosten an, man kann eine Weiterverrechnung auf Basis von Netzwerkports, Plattenplatz, Geschwindigkeiten usw. durchfhren. Des Weiteren bieten die meisten LAN-Komponenten zurzeit nur sehr rudimentre oder gar keine Accounting-Mglichkeiten, so dass nicht selten die notwendigen technischen Mglichkeiten gar nicht gegeben sind. Im Bereich der ffentlichen Netze addieren sich zu den Kosten fr das Equipment und den Betrieb die teilweise recht hohen Gebhren, die an die Carrier auf zeit- oder volumenabhngiger Basis zu entrichten sind. Diese Kosten will man in der Regel nicht in einem festen Verhltnis auf die Kostenstellen umlegen, da nicht jede Organisationseinheit die Dienste in gleichem Mae in Anspruch nimmt. Es sollen vielmehr die tatschlich verursachten Kosten ermittelt und weiter verrechnet werden. Somit findet man insbesondere im Remote-AccessBereich Accounting-Funktionalitten, die eine zeit- und volumenabhngige Abrechnung der Dienste ermglichen. Auch im Bereich der traditionellen WAN-Router findet man zunehmend Abrechnungsfunktionen auf IP-Ebene. Lst man diese herkmmlichen Strukturen nun durch die VPN-Technologie ab, mssen diese Accounting-Systeme ebenfalls untersttzt werden, auch im parallelen Betrieb whrend der Migrationsphase. RADIUS (Remote Authentication Dial In User Service, ein Standard, der Protokolle und Funktionen zur Authentifizierung, Autorisierung und zum Accounting von Remote-AccessBenutzern beschreibt) hat sich im Laufe der Jahre zu einem weit verbreiteten Standard mit hoher Interoperabilitt zwischen verschiedenen Herstellern entwickelt. Praktisch alle Remote-Access-Systeme, sowohl im Enterprise- als auch im Carrier-Umfeld, arbeiten mit RADIUS zur Benutzer-Authentifizierung und zum Accounting. Um die Datenstze auszuwerten, die von RADIUS-Servern erzeugt werden, gibt es mittlerweile eine Flle von Programmen. Das Format eignet sich auch zum direkten Importieren in verbreitete Applikationen wie Datenbanken oder Tabellenkalkulationsprogramme.
79
Aus diesen Grnden liegt es auf der Hand, dass VPN-Systeme RADIUSAccounting untersttzen mssen. Dadurch knnen sie einfach und schnell in eine bestehende Infrastruktur integriert werden.
3.6.2
Sicherheit
Sicherheitsstrategie Ein VPN muss sich reibungslos in die Sicherheitsstrategie einer Organisation integrieren lassen. Die Sicherheitsstrategie, auch als Security Policy bezeichnet, ist eine unternehmensweite Definition von Sicherheitsanforderungen, die eine ganze Reihe von Bereichen abdecken mssen, wie zum Beispiel die Behandlung von Kennwrtern, physikalischer Zugangsschutz, Zugriffsregelung auf kritische Ressourcen usw. Sie beschreibt dabei sowohl die Anforderungen als auch die Zustndigkeitsbereiche fr deren Umsetzung. Eine gute Sicherheitsstrategie definiert dabei nicht, welche Technologien eingesetzt werden, oder bestimmte Schlssellngen, dies ist Aufgabe der fr die Umsetzung verantwortlichen Organisationseinheiten. Die Security Policy legt lediglich fest, welche Daten ber welchen Zeitraum, vor welchen potenziellen Angriffen und durch wen zu schtzen sind. Dies klingt einfach und ist es auch. Was komplex ist, ist ihre konsistente Umsetzung. Eine Sicherheitsstrategie legt zum Beispiel fest, dass die Konstruktionsdaten eines Unternehmens mindestens zwanzig Jahre auch vor Zugriffen durch fremde Geheimdienste sicher sein mssen, und benennt optional noch die dafr verantwortlichen Organisationseinheiten. Das war es auch schon, denn die Umsetzung obliegt den betroffenen Organisationseinheiten, die mit diesen Daten umgehen. Im Netzwerkbereich leiten sich daraus die entsprechenden Kriterien ab, um die bertragungen sowohl im Intranet als auch im Weitverkehrsnetz oder VPN durch starke Verschlsselung zu schtzen. Authentifizierung blicherweise sind fr Benutzer, die sich per Remote Access in das Unternehmensnetzwerk einwhlen, in der Sicherheitsstrategie bestimmte Anforderungen hinsichtlich der Authentifizierung festgelegt. Im lokalen Netzwerk kann man sich ohne besondere Authentifizierung anschlieen, denn hier sieht die Security Policy des Unternehmens in der Regel einen physikalischen Zugangsschutz vor, meist per Magnetkarte am Eingang der Gebude. Dieser Zugangsschutz entfllt beim Remote Access natrlich und muss durch besondere Verfahren zur Identittsfeststellung nachgebildet werden. Dies trifft auf den traditionellen Remote Access und Remote-Access-VPNs gleichermaen zu.
80
Firewalls In den meisten Organisationen wird heute ein Internetanschluss betrieben. Da man aus Sicherheits- und anderen Grnden (z.B. wegen der Verwendung privater, nicht registrierter IP-Adressen) sein Intranet nicht direkt mit dem Internet verbinden kann, wird diese Funktion in der Regel von so genannten Firewalls vorgenommen. Eine Firewall kontrolliert den gesamten Datenverkehr zwischen Systemen im Internet und dem Intranet. Sie soll einerseits verhindern, dass sich Unbefugte Zugang zum Intranet verschaffen, und andererseits den Datenverkehr kontrollieren, den Systeme im Intranet in das Internet leiten. Hierbei werden die Datenpakete sogar bis auf die Ebene der Dateninhalte geprft, um zum Beispiel Webseiten mit moralisch fragwrdigem Inhalt zu sperren. Der wichtige Punkt hierbei ist, dass eine Firewall den Verkehr in das Internet kontrolliert. Ein Internet-VPN greift hingegen auf kein einziges Internet-System zu, sondern es benutzt das Internet lediglich als Transportmedium fr IP-Pakete. Dies ist eine vllig andere Situation, da die IP-Pakete ausschlielich im privaten Bereich versendet und empfangen werden. Querverbindungen in das Internet sind bei einigen sehr guten, dedizierten VPN-Systemen berhaupt nicht mglich. Aus diesem Grund macht es auch wenig Sinn (und kann von Fall zu Fall sogar Probleme bereiten), wenn man beide Funktionalitten auf einem System zusammenfhrt, egal ob man VPN-Funktionen in eine Firewall integriert oder umgekehrt eine Firewall in einen VPN-Konzentrator. Vielmehr ist zu fordern, dass der VPN-Konzentrator als Ablsung klassischer Netzwerkkomponenten wie Router oder Remote-Access-Konzentratoren und die Firewall gleichzeitig nebeneinander zu betreiben sind. PKI Technologien wie E-Business oder E-Commerce und neu geschaffene rechtliche Rahmenbedingungen fr digitale Unterschriften haben zusammen mit einem gestiegenen Sicherheitsbedrfnis bei der Benutzung ffentlicher Netze eine Reihe von Applikationen hervorgebracht, die mit elektronischen, digitalen Schlsseln Daten verschlsseln oder Dokumente signieren. Bei groen Organisationen fallen dabei eine ganze Reihe verschiedener Schlssel an, die erzeugt, verwaltet, regelmig erneuert und vor allem eindeutig bestimmten Personen zugeordnet werden mssen. Eine Public-Key-Infrastruktur (PKI) leitet ihren Namen von der so genannten Public-Key-Kryptographie (vgl. Kapitel 4) ab, bei der mit zwei verschiedenen Schlsseln, einem ffentlichen und einem privaten, gearbeitet wird. Mit einem Schlssel (Public Key, dem ffentlichen Schlssel) wird verschlsselt und mit dem anderen (Private Key, dem privaten, geheimen Schlssel) wieder
81
entschlsselt. Die beiden Schlssel bilden ein Paar; der ffentliche Schlssel ist jedermann zugnglich und ist fest an eine Person gebunden, und der private wird von der Person geheim gehalten. Etwas, das mit dem einen Schlssel verschlsselt wurde, kann nur mit dem korrespondierenden anderen Schlssel wieder entschlsselt werden. Die Bindung einer Person an einen ffentlichen Schlssel erfolgt ber ein so genanntes digitales Zertifikat. Die Erzeugung und Verwaltung dieser Zertifikate, die Registrierung der Benutzer und das Erzeugen und Speichern von Schlsselpaaren zum Zweck der Datenverschlsselung auf Rechnern ist die Hauptfunktion einer PKI. Diese kann sowohl von einem Unternehmen selbst betrieben werden, oder man benutzt eine ffentliche PKI. Falls nun digitale Zertifikate zum digitalen Signieren eingesetzt werden, liegt es auf der Hand, diesen Mechanismus auch zur Authentifizierung von Benutzern oder VPN-Systemen einzusetzen. Hier sollten die VPN-Gerte und die Clientsoftware eine entsprechende Untersttzung bieten.
3.7
Koexistenz zu traditionellen WAN-Strukturen
blicherweise findet nicht immer sofort eine Ablsung von traditionellen Netzen durch virtuelle private Netze statt. Vielmehr mssen beide fr eine gewisse Migrationsphase gleichzeitig zu betreiben sein. Typische Flle sind der gleichzeitige Einsatz von VPNs und Frame-Relay- oder ATM-Netzen, da es oft der Fall ist, dass die beiden letztgenannten Technologien nicht an jedem bentigten Standort zur Verfgung stehen. Auch normaler Remote Access per Einwahl ber das Telefonnetz wird sehr oft parallel zum VPN-Remote-Access betrieben. Hier sollen aus Kostengrnden zwar mglichst viele Verbindungen ber das VPN laufen, jedoch nutzt man den Einwhlteil oft als Backup oder fr bestimmte kritische Applikationen, die eine garantierte Einwahl und bestimmte Qualittsmerkmale bentigen. Um das Ratiopotenzial eines VPN voll ausschpfen zu knnen, drfen Einsparungen, die auf der einen Seite durch geringere Gebhren und gnstigeres Equipment erzielt wurden, nicht durch andere, durch die VPN-Technologie anfallende, neue Kosten zunichte gemacht werden. Solche Kosten sind oft versteckt und auf den ersten Blick vielleicht gar nicht mit dem Einsatz eines VPN in Zusammenhang zu bringen. Einer der negativen Kostenfaktoren, vielleicht der schwerwiegendste, sind erhhte Managementkosten. Diese knnen erzeugt werden, wenn sich die VPN-Systeme nicht in das vorhandene Netzwerkmanagement integrieren lassen und ein paralleles Management aufgebaut wird.
82
Adressmanagement
Auch Zusatzkosten durch mglicherweise erforderliche IP-Adressnderungen in einem groen Netzwerk sollten vermieden werden, indem man die VPN-Technologie in bestehende Strukturen integriert und nicht umgekehrt bestehende Strukturen an das VPN anpasst.
3.8
Adressmanagement
Das IP-Adressmanagement ist in vielen Unternehmen zunehmend zu einem kritischen Faktor geworden. Dies hat historische Grnde, die mit der Entwicklung und Einfhrung des IP-Protokolls zu tun haben. IP war viele Jahre ein Protokoll, das fast ausschlielich im Internet eingesetzt wurde. Die Folge war, dass alle beteiligten Gerte offizielle IP-Adressen und etliche Organisationen und Firmen offizielle IP-Netze zugeteilt bekamen. Als TCP/IP praktisch Bestandteil von Unix wurde, es als kostenloser Zusatz fr Windows 3.x verfgbar war und Betriebssysteme wie VM oder OS/400 von IBM ebenfalls damit ausgerstet wurden, gab es ein paar Entwicklungen, an denen viele Unternehmen heute noch zu knabbern haben. Denn in vielen Firmen begannen sich regelrechte IP-Inseln zu bilden, oft mit selbst vergebenen, nicht registrierten Adressbereichen. Zuerst wollte man berhaupt keinen Internetzugriff, im Zeitalter des World Wide Web wurde dieser Wunsch von den Anwendern jedoch immer dringlicher vorgetragen. Als Ausweg boten sich Firewalls mit NAT (Network Address Translation, Umsetzung von nicht registrierten in offizielle IP-Adressen) an. Im Intranet der Unternehmen wurden bis dato die IP-Adressen manuell vergeben und statisch auf den Systemen eingetragen. Dokumentiert wurde meist nichts, und wenn doch, dann waren die Daten oft nicht aktuell und unvollstndig. Im Verlauf dieser und anderer Entwicklungen wurde der Ruf nach einem einfachen und automatischen Management der IP-Adressen immer lauter. Das Resultat war das DHCP (Dynamic Host Configuration Protocol), ein Verfahren mit dem IP-Schnittstellen automatisch und dynamisch von einem speziellen Server konfiguriert werden. DHCP ist eine Client-Server-Applikation, bei der die Clients beim Start eines Rechners mit einer IP-Schnittstelle von einem DHCP-Server eine IP-Adresse und weitere optionale Konfigurationsparameter anfordern. Es hat mittlerweile eine recht breite Verwendung gefunden. Neben Implementierungen in PC-Betriebssystemen gibt es auch professionelle, hoch skalierbare Systeme, die mit relationalen Datenbanken arbeiten, und einen dynamischen DNS-Server (Domain Name System, ein Verfahren, um Systeme statt mit ihrer IP-Adresse ber einen Namen anzusprechen) integriert haben, der die sich ndernden IP-Adressen immer dem korrekten Domainnamen zuordnet.
83
IPSecClient
VPNKonzentrator
Intranet
Internet
Offizielle, statische IP-Adresse
Dynamische, offizielle, vom Provider zugewiesene IP-Adresse
DHCPServer
DHCP-Request
Die private IP-Adresse wird dem Client ber das IKE-Protokoll fr die Dauer der Verbindung zugewiesen DHCP-Offer mit einer privaten IP-Adresse fr den Client
Abbildung 3.7: Das IP-Adressmanagement in IP-VPNs muss gut geplant werden.
Viele heute eingesetzte Remote-Access-Konzentratoren verwenden DHCP, um den Clientrechnern eine IP-Adresse dynamisch zuzuweisen. Diese Funktionalitt muss ein VPN-Konzentrator ebenfalls untersttzen, um in das unternehmensweite IP-Adressmanagement integrierbar zu sein. Idealerweise ist sowohl ein gerichtetes DHCP mglich, bei dem sich die Systeme an dedizierte DHCP-Server wenden, als auch ein ungerichtetes, bei dem per Netzwerkbroadcast ein passender Server gesucht wird. Die Anforderungen im Bereich der IP-Adressverwaltung beschrnken sich jedoch keinesfalls nur auf DHCP, es mssen auch andere Mechanismen zur Zuteilung von IP-Adressen untersttzt werden. Hierbei resultieren die Anforderungen sowohl aus der aktuellen Managementumgebung als auch aus zuknftig einzusetzenden Systemen. Insbesondere arbeiten viele RemoteAccess-Konzentratoren mit RADIUS-Servern, auf denen neben der Authentifizierung und dem Accounting auch IP-Adressen userbezogen oder aus einem so genannten Pool heraus vergeben werden. Auch eine gertesspezifische Vergabe von IP-Adressen auf Basis von Benutzernamen oder aus einem Pool sollte von einem modernen VPN-Konzentrator untersttzt werden. Directory Services (Verzeichnisdienste) erfreuen sich in der Fachwelt einer immer greren Beliebtheit. Nachdem in der Vergangenheit einige proprietre Verfahren wie Novell NDS oder Banyan Streettalk und Standards wie X.500 miteinander konkurriert hatten, konzentriert sich die Entwicklung momentan auf das Lightweight Directory Access Protocol (LDAP). Es wird mittlerweile von allen Gren der Netzwerkindustrie sowohl im Bereich der Betriebssysteme als auch im Bereich der Netzwerkkomponenten und Managementsys-
84
Interoperabilitt
teme eingesetzt. LDAP ist sehr flexibel und bietet einen fest spezifizierten Satz von Funktionen und Formaten zum Erzeugen, Modifizieren, Abfragen und Lschen von Eintrgen in der Verzeichnisdatenbank. Die Struktur eines Verzeichnisses ist frei whlbar und kann somit magerecht an unterschiedliche Bedrfnisse angepasst werden. Ein VPN-System, das auch noch in der Zukunft einsetzbar sein soll, muss daher ebenfalls LDAP untersttzen knnen, um in unternehmensweite Verzeichnisdienste integrierbar zu sein.
3.9
Interoperabilitt
Interoperabilitt ist eine wichtige und kritische Anforderung an heutige VPNKonzentratoren und VPN-Gateways. Dies hat gleich mehrere Grnde. Je nach Auswahl eines geeigneten Tunneling-Modells (vgl. Kapitel 6) knnen mehrere Partner an einem VPN beteiligt sein (zum Beispiel ein Internet Service Provider und der Endkunde), die unter Umstnden Equipment verschiedener Hersteller einsetzen. Ein anderes Beispiel fr die Notwendigkeit der Interoperabilitt verschiedener VPN-Systeme ist die Dynamik im Bereich von Firmenzusammenschlssen oder Kooperationen, die in der heutigen Zeit zu beobachten ist. Hierbei knnen in den unterschiedlichen Unternehmen Anforderungen der Art entstehen, dass die eingesetzten VPN-Gerte miteinander kommunizieren mssen. Das Automotive Network Exchange (ANX) ist beispielsweise ein VPN, das fr Automobilhersteller und Zulieferer mit unterschiedlichsten Gerten auf der Basis des IPSec-Protokolls betrieben wird. Dies erfordert, dass das jeweils verwendete Equipment mit den Gegenstellen interoperabel ist. Die Lsung besteht darin, ausschlielich solche Protokolle einzusetzen, die standardisiert und allgemein akzeptiert sind. Leider hat die Vergangenheit gezeigt, dass auch standardkonforme Implementierungen bestimmter Datenkommunikationsprotokolle keineswegs ein Garant fr eine reibungslose Kommunikation sind. Dies liegt an der Tatsache, dass viele Protokolle sehr flexibel sein mssen und gegebenenfalls so konfiguriert werden knnen, dass eine Kommunikation mit anders konfigurierten Gegenstellen unmglich ist. Wichtig ist daher, dass es eine oder mehrere mgliche Konfigurationen der Protokolle gibt, bei denen eine Interoperabilitt gewhrleistet oder sogar nachgewiesen ist. Insbesondere im Bereich des IPSec-Protokolls ist dies zu fordern. ICSA.net ist eine sich selbst als unabhngig bezeichnende Firma, die sich mit Internet-Sicherheit beschftigt. Die ICSA Labs fhren Tests durch, die die Funktionalitt und Interoperabilitt von IPSec-Implementierungen ermitteln sollen. Gerte oder Programme, die erfolgreich getestet wurden, drfen
85
das ICSA-IPSec-Logo tragen und sind, was viel wichtiger ist, mit einer sehr hohen Wahrscheinlichkeit zu anderen zertifizierten Systemen interoperabel.
86
Sicherheitstechnologie
In diesem Kapitel werden die Sicherheitsaspekte beim Einsatz von VPNs betrachtet und die hierfr eingesetzten Technologien ausfhrlich behandelt. Zuerst erfolgt ein allgemeiner berblick, mit welchen Techniken die Sicherheitsanforderungen erfllt werden, die wir im vorangegangenen Kapitel an virtuelle private Netzwerke gestellt haben. Anschlieend werden die Grundlagen fr diese Technologien ausfhrlich behandelt, wobei jedoch immer der aktuelle Bezug zum Thema VPNs bestehen bleibt. Insbesondere werden nur solche Algorithmen und Verfahren besprochen, die in aktuellen Netzwerk-Sicherheitsprotokollen verwendet werden, so dass hier auch nur Teilaspekte der Kryptologie behandelt werden. Allgemeine und umfassende Grundlagen zum Thema Kryptologie und verwandte Themen finden Sie in der weiterfhrenden Literatur hierzu.
4.1
Sicherheit in VPNs
Dieses Thema kann und darf nicht isoliert betrachtet werden. Es ist ein integraler Bestandteil der Netzwerksicherheit, die wiederum nur ein kleiner Teil einer unternehmensweiten Sicherheitsstrategie ist.
4.1.1
Sicherheit in Unternehmensdatennetzen
Der Aspekt Sicherheit spielte in der Vergangenheit aufgrund der Begrenzung der Datennetze auf das Unternehmensgelnde und der noch bersichtlichen Anzahl von Weitverkehrsverbindungen eine eher untergeordnete Rolle. Ausgelst durch vernderte Arbeits- und Kommunikationsweisen beginnt sich dies zu ndern. Die Zahl der so genannten Remote-Access-Nutzer, also der Mitarbeiter, die von unterwegs, von einer Auenstelle oder von zu Hause aus Zugriff auf Daten des Firmennetzes bentigen, steigt kontinuierlich. Damit ist das Firmennetz nicht mehr lnger auf den Campus begrenzt, sondern es mssen eine Vielzahl von Remote-Access-Verbindungen eingerichtet, betrieben und berwacht werden. Immer mehr Unternehmen ffnen ihre Firmennetze fr Zulieferer, Partner und Kunden bzw. bieten ihre Produkte auf elektronischem Weg zum Verkauf an. Hierfr sind nationale und internationale Verbindungen notwendig. Da der Aufbau bzw. das Anmieten eines eigenen Leitungsnetzes aber
87
4 Sicherheitstechnologie
fr die wenigsten Firmen rentabel ist, werden fr solche Anwendungen vermehrt ffentliche Netze wie das Internet oder Teilkapazitten ffentlicher Netze als so genannte virtuelle private Netze genutzt. Gleichzeitig hat das Netz fr den wirtschaftlichen Erfolg des Unternehmens einen weit hheren Stellenwert als in der Vergangenheit. Denn je mehr geschftskritische Anwendungen darber miteinander kommunizieren und je mehr unternehmenskritische Ressourcen daran angeschlossen werden, desto mehr wird das Netz selbst zum geschftsbestimmenden Faktor. Damit stellt sich automatisch die Frage nach der Datensicherheit und anderen mit ihr zusammenhngenden Aspekten wie Sicherung des Netzzugangs, Systemsicherheit auf Rechner- und Programmebene oder Zugriffsschutz auf gespeicherte Informationen. Datensicherheit ist ein komplexes Thema. Zum einen, weil die Sicherheitstechnologien selbst komplex sind und unterschiedliche Funktionen und damit einen unterschiedlichen Grad an Sicherheit bieten. Zum anderen, weil die Datensicherheit immer auch vom Gesamtsicherheitskonzept des Unternehmens betroffen ist. Insofern muss der Einfhrung von Sicherheitstechnologien eine Sicherheits- beziehungsweise Gefahrenanalyse vorausgehen, die wenigstens folgende Fragen beantworten sollte: Was ist wem gegenber wie lange vertraulich zu behandeln? Welche Manahmen mssen von wem dementsprechend eingeleitet werden, und was drfen sie kosten? Welche Risiken bestehen fr das Unternehmen und wie sind sie zu bewerten? Geschtzt werden mssen im Wesentlichen die Systemhardware und -software sowie die Daten selbst. Dabei geht man meist davon aus, dass die Daten das am meisten bedroht sind. Die Hardware kann in Sicherheitsbereichen oder im Hot-Standby-Mode betrieben werden, so dass Angriffe, sofern sie berhaupt mglich sind, schnell bemerkt und aufgefangen werden knnen. Das gleiche gilt fr die Software, die auf diesen Systemen luft. Viele Daten mssen vertraulich sein, also vor Aussphung geschtzt werden. Und sie mssen integer sein, also vor unerlaubten Vernderungen geschtzt werden. Gleichzeitig mssen Daten aber auch verfgbar sein. Hier liegt das Problem, denn 100% sichere Daten sind nicht mehr verfgbar, und 100% verfgbare Daten sind nicht mehr sicher. Als praktikable Lsung bleibt demzufolge nur ein Kompromiss zwischen Verfgbarkeit und Sicherheit.
88
Sicherheit in VPNs
Aus diesem Grund muss der Einfhrung von Sicherheitstechnologien zunchst eine Datenanalyse vorausgehen, die Fragen wie diese beantwortet: Welche Arten von Daten sind im Unternehmen vorhanden? Wie sicher mssen diese Daten sein? Vor wem mssen sie sicher sein? Wie hoch sind die Verletzungen der Sicherheit zu bewerten? Wie lange muss die Sicherheit, insbesondere die Vertraulichkeit, gewhrleistet sein Stunden, Tage, Wochen, Monate, Jahre oder Jahrzehnte? Zu welchem Preis (Kosten, Verfgbarkeit, Benutzbarkeit) drfen diese Ziele erreicht werden? Die Konzernbilanz eines Unternehmens muss in der Regel nur kurze Zeit vertraulich behandelt werden, und selbst wenn whrend dieser Zeit Einzelheiten an die ffentlichkeit dringen, wre das Unternehmen dadurch nicht unbedingt existenziell gefhrdet. Wenn andererseits aber Firmengeheimnisse wie Entwicklungsdaten, Patente oder vergleichbar sensible Informationen bekannt werden, kann das Unternehmen erheblichen Schaden davontragen, ja sogar in seiner Existenz gefhrdet sein. Ebenso hat die Analyse, von wem ein Unternehmen bedroht wird, starke Auswirkungen auf die einzufhrende Sicherheitstechnologie. Eine Firma, die von einer Privatperson angegriffen wird, muss sich weniger schtzen als eine, die befrchten muss, von einem Konkurrenzunternehmen oder gar von einem Geheimdienst ausgespht zu werden. Denn letzteren stehen fr einen Angriff ganz andere finanzielle Mittel und technische Ressourcen zur Verfgung als einer Privatperson. Entsprechend mehr Sicherheit zu hheren Kosten wird sich das betroffene Unternehmen anschaffen mssen. Aspekte dieser Art wirken sich direkt auf technische Details aus, zum Beispiel auf die Schlssellnge bei der Datenverschlsselung, auf das einzusetzende Verschlsselungsverfahren oder auf die Kombination von mehreren Sicherheitstechnologien. Nicht zu unterschtzen ist darber hinaus der Einfluss, den die Anschaffung neuer sicherheitsrelevanter Technologien, wie zum Beispiel virtueller privater Netzwerke auf bereits vorhandene Einrichtungen hat, vor allem wenn durchgngige Sicherheitskonzepte in einer verteilten Systemumgebung realisiert werden sollen. Beispielsweise knnen aus technischen Grnden bestimmte Authentifizierungsverfahren nicht zusammen mit bestimmten Benutzer- oder Passwort-Verwaltungssystemen eingesetzt werden. Um auszuschlieen, dass sich Neuanschaffungen negativ auf vorhandene Technologien auswirken oder gar neue Bedrohungen nach sich ziehen, sollte vorab geklrt werden:
89
wie die augenblickliche Systemsicherheit, insbesondere die Zugriffskontrolle auf Rechner- und Programmebene, realisiert ist, wie die Datensicherheit, also die Zugangskontrolle auf Dateiebene, organisiert ist, ob und welche Zugangskontrollen es zu Gebuden, Rumen oder Zonen gibt und welche gesetzlichen Auflagen und betrieblichen Zwnge bei der Einfhrung bercksichtigt werden mssen. Auerdem mssen verbindliche Richtlinien darber existieren, wer fr die Sicherheit verantwortlich ist. Hiervon sind alle Mitarbeiter einer Organisation betroffen, von den Systemadministratoren und Netzverantwortlichen bis hin zu jedem Endbenutzer. Denn was nutzt das ausgefeilteste und teuerste Netzund Systemzugangskonzept, wenn der Mitarbeiter sein Passwort an den PCBildschirm klebt.
4.1.2
Die Sicherheit von virtuellen privaten Netzen
Ein entscheidendes Kriterium beim Entwurf einer Kommunikationsinfrastruktur, die ffentliche Netze benutzt, sei es ISDN, PSTN, GSM, ein ProviderNetzwerk oder das Internet, ist die Sicherheit der zu bertragenden Daten. Diese mssen insbesondere gegen Verletzungen der Vertraulichkeit und der Integritt hinreichend geschtzt werden, gefolgt von flankierenden Manahmen zum Schutz vor Denial-of-Service- und Replay-Angriffen und weiteren hnlich gearteten Attacken. Die Anforderungen an die Sicherheit eines VPN leiten sich aus der Sicherheitsstrategie (Security Policy) oder den allgemeinen Anforderungen an die Sicherheit des Unternehmensnetzwerks ab. In der Vergangenheit wurde dies, meist weil die geeignete Technologie fehlte, durch die Verschlsselung von einzelnen Teilstrecken, durch die Verbindungsverschlsselung (Link-Encryption) oder die Verschlsselung auf Applikationsebene gelst. Mit der Verbindungsverschlsselung werden die Verbindungen zwischen Vermittlungs- oder bertragungssystemen oder die Pakete auf der Verbindungsschicht, der Schicht 2 des OSI-Schichtenmodells, verschlsselt. Das immanente Sicherheitsproblem hierbei liegt in der Dynamik heutiger Netzwerke. Auf der Ebene der Netzwerk-Infrastruktur werden laufend neue Strecken hinzugefgt oder gendert, und die Vermittlungssysteme, die zwischen den verschlsselten Links sitzen, befinden sich nicht im Einflussbereich des Endteilnehmers beziehungsweise des Endkunden. Auf diesen Vermittlungssystemen liegen die Daten aber unverschlsselt vor, da ja nur auf den Verbindungswegen selbst verschlsselt wird. Ein weiteres Problem der Verbindungsverschlsselung ist die automatische Wegewahl (Routing)
90
Sicherheit in VPNs
beim Transport von Paketen durch ein Netzwerk, die bei modernen gerouteten Netzwerken nicht mehr vorherbestimmbar ist. Somit besteht die Gefahr, dass Daten ber nicht verschlsselte Teilstrecken transportiert werden. Vom Standpunkt der Datensicherheit wre die beste Methode eine Ende-zuEnde Verschlsselung auf Applikationsebene. Dies ist aber technisch und organisatorisch nicht mehr handhabbar, insbesondere wenn man viele verschiedene Applikationen einsetzt und diese einer gewissen Dynamik unterworfen sind. Die Lsung heit hier Verschlsselung auf Netzwerkebene, also auf der Schicht 3 des OSI-Schichtenmodells. Hier kann man, je nach Anforderung und Infrastruktur, auch gemischt Sicherheit von Rechner zu Rechner, von Rechner zu Netzwerk oder von Netzwerk zu Netzwerk realisieren. Die Sicherheit auf hheren Ebenen anzusiedeln, hat fr ein virtuelles privates Netzwerk schon wieder mehr Nach- als Vorteile, da hierbei wieder niemals alle Daten verschlsselt werden knnen. Ein VPN ist ein Netzwerk oder zumindest ein Teil eines Gesamtnetzwerks, also ist die notwendige Sicherheitstechnologie auch auf dieser Ebene, der Netzwerkebene, anzuwenden. Da die Sicherheit des Datentransports in einem IP- oder Internet-VPN so wichtig ist, werden einige Aspekte und Lsungen im Folgenden detailliert erlutert.
4.1.3
Die Datenvertraulichkeit ist eine wichtige Anforderung an virtuelle private Netze, falls die Daten, die darber transportiert werden, im Klartext vorliegen und vertraulich oder sogar geheim sind. Es darf also kein Unbefugter Daten, die er sich durch geeignete Abhrmanahmen verschafft hat, lesen knnen. Dies erreicht man durch eine Verschlsselung der Informationen durch den Absender. Der Empfnger macht die Informationen durch eine Entschlsselung wieder lesbar. Die technischen Details einer solchen Verschlsselung werden im Laufe dieses Kapitels noch eingehend behandelt werden. Es gibt mehrere Anstze zur verschlsselten bertragung von Daten, die sich im Wesentlichen darin unterscheiden, auf welcher Ebene des OSI-Schichtenmodells sie eingesetzt werden. Die unterschiedlichen Mglichkeiten sind: Verschlsselung auf Ebene 1, der physikalischen Schicht (z.B. Lichtwellen) Verschlsselung auf Ebene 2, der Sicherungsschicht ( z.B. PPP) Verschlsselung auf Ebene 3, der Vermittlungsschicht (z.B. IP, IPX) Verschlsselung auf Ebene 4, der Verbindungsschicht (z.B. TCP, UDP, SPX)
91
Verschlsselung auf Ebene 5, der Sitzungsschicht (z.B. HTTP) Verschlsselung auf Ebene 6, der Darstellungsschicht Verschlsselung auf Ebene 7, der Applikationsschicht (z.B. PGP) Fr ein Internet-VPN kommt man sehr schnell zu der Erkenntnis, dass eine Verschlsselung auf der Vermittlungsschicht, also auf der Ebene des IP-Protokolls, das Sinnvollste und Sicherste ist. Warum ist dies so? Sehen wir uns zuerst einmal die Mglichkeiten an, auf den unteren Ebenen 1 und 2 zu verschlsseln. Dabei verschlsseln wir Datenleitungen oder Datenrahmen auf der Sicherungsschicht. Wer eine solchermaen verschlsselte Leitung abhrt, kann mit den abgefangenen Daten nichts anfangen. Aber in den Vermittlungssystemen liegen die Daten im Klartext vor, da sie in der Schicht 3 verarbeitet werden, an die sie daher unverschlsselt von der Sicherungsschicht geliefert werden mssen. Jemand, der sich Zugriff auf ein solches System verschafft, kann auch auf die unverschlsselten Informationen zugreifen. Ein anderes Problem besteht darin, dass in modernen Netzen eine dynamische Wegwahl fr die Datenpakete erfolgt, um sie so schnell und so kostengnstig wie mglich zu transportieren. Daraus folgt aber auch, dass der Weg, den die Datenpakete nehmen, nicht vorherbestimmbar ist und deshalb alle mglichen Teilstrecken verschlsselt werden mssen. Das ist aufgrund der Komplexitt weder im Internet noch in Frame-Relay- oder ATM-Netzen realisiert und wird dort auch nicht realisiert werden. Setzen wir nun an anderer Stelle an, und schauen wir uns einmal die Verschlsselung auf den hheren Ebenen, also den Schichten 4 bis 7 an. Im Extremfall (Schicht 7) erfolgt die Ver- und Entschlsselung durch die Anwendungen. Es mssen dabei natrlich alle mglichen Anwendungen mit den entsprechenden Funktionen ausgerstet werden, um den gesamten Datenverkehr sicher zu machen, was sowohl technisch als auch organisatorisch nicht mglich ist. Auch auf tieferen Ebenen bleibt immer das Problem bestehen, dass alle gleichzeitig betriebenen Anwendungen, Protokolle und Verbindungen mit entsprechenden Verschlsselungsfunktionen ausgerstet sein mssen, sollen nicht einige Informationen doch noch im Klartext bertragen werden. Die Ebene 3 weist in einem IP- oder Internet-VPN diese ganzen Nachteile nicht auf, da dort nur ein einziges Protokoll, nmlich das Internet-Protokoll (IP), betrieben wird. Integriert man seine Sicherheitstechnologie in das IP-Protokoll, dann werden alle Datenpakete dieses Protokolls von den eingesetzten Sicherheitsverfahren bearbeitet, unabhngig von der darunter liegenden Infrastruktur und unabhngig von den Anwendungen darber. Wie eingangs erwhnt, kann man in einigen wenigen, speziellen und klar abgegrenzten Fllen auch ohne IP-Sicherheitstechnologie in Internet-VPNs auskommen und zwar dann, wenn alle Applikationen oder Protokolle, die das
92
Sicherheit in VPNs
VPN benutzen, bereits entsprechende Sicherheitsfunktionen untersttzen. Falls zum Beispiel in einem Remote-Access-VPN die Benutzer ausschlielich webbasierende Anwendungen und E-Mail benutzen, dann kann man bei der Verwendung des SSL-Protokolls und eines sicheren Mailsystems wie zum Beispiel PGP (Pretty Good Privacy, ein kryptographisch geschtztes Mailsystem) die notwendige Sicherheit auch ausschlielich auf hheren Ebenen des OSISchichtenmodells ansiedeln. Aber wehe, wenn auch nur einer der Benutzer in einem derart aufgebauten VPN ein anderes Kommunikationsprogramm benutzt. Dann ist alles, was damit bertragen wird, ungesichert!
4.1.4
Sicherheit in der Netzwerkschicht mit IP Security
Da man beim Design eines VPN auf Skalierbarkeit und Migrationsfhigkeit Wert legen sollte, ist es ein Muss, so weit es irgend mglich ist, mit Standards zu arbeiten. Der Standard fr Sicherheit auf der IP-Ebene heit IP Security oder kurz IPSec. In ihm sind verschiedene Verschlsselungs- und Authentifizierungsverfahren sowie Schlsseltausch- und Schlsselverwaltungsprotokolle festgelegt, die bei korrekter Implementierung eine hohe Interoperabilitt gewhrleisten. Im Folgenden werden die fr ein IP-VPN essenziellen Sicherheitsmerkmale dieses relativ neuen Protokolls behandelt, in Kapitel 7 werden die technischen Aspekte des IPSec-Protokolls ausfhrlich beschrieben. Datenverschlsselung in IPSec In IPSec knnen die Daten auf verschiedene Arten verschlsselt werden, also mit den unterschiedlichsten Algorithmen und unterschiedlichen Schlssellngen. Wichtig dabei ist, dass sich die beteiligten Gegenstellen immer auf ein Verfahren einigen knnen. Aus diesem Grund gibt es einen Verschlsselungsalgorithmus, der von jeder IPSec-Implementierung untersttzt werden muss, den Data Encryption Standard (DES) mit seiner festen Schlssellnge von 56 Bit. Viele Implementierungen bieten auch optional das strkere Triple-DESVerfahren mit einer Schlssellnge von insgesamt 168 Bit, es ist jedoch nicht vom Standard vorgeschrieben. Um zu vermeiden, dass identische Klartextblcke nach der DES-Verschlsselung identische Chiffretextblcke erzeugen, ist in IPSec das so genannte Cipher-Block-Chaining-Verfahren (CBC) vorgeschrieben, das diesen Mangel von DES behebt. Datenintegritt und Datenauthentizitt in IPSec Die Datenintegritt, also der Schutz vor unerlaubter und unbemerkter Vernderung der Datenpakete, wird in IPSec durch spezielle, kryptographisch geschtzte Prfsummen, genannt HMAC (Hash-based Message Authentication Code, Prfsummen, die durch Hashfunktionen berechnet wurden), erreicht. Das gleiche Verfahren garantiert auch die Feststellung der Authentizitt eines IP-Pakets. HMACs basieren auf Einwegfunktionen, die aus den zu
93
schtzenden Daten und einem Schlssel einen Wert erzeugen, der nicht mehr zurckzuberechnen ist, auch nicht bei Kenntnis eines der Eingangsparameter. In IPSec werden zwei Funktionen vorgeschrieben, HMAC-MD5 und HMAC-SHA-1, die auf den Hashfunktionen MD5 und SHA-1 aufgebaut sind und mit symmetrischen Schlsseln von 128 Bit Lnge arbeiten. Auch in diesem Bereich garantiert der Standard eine hohe Interoperabilitt. Schlsselmanagement in IPSec Die Verfahren zur Datenverschlsselung, Authentifizierung und Integrittsprfung bentigen auf beiden Seiten einer so genannten IPSec-Sicherheitsassoziation jeweils die gleichen Schlssel. Der DES-Algorithmus bentigt auf der Empfngerseite den gleichen 56 Bit groen Schlssel zum Entschlsseln, mit dem der Sender die Daten verschlsselt hat. Ebenso bentigt z.B. HMACMD5 auf beiden Seiten einen identischen 128 Bit langen Schlssel zur Integrittsprfung und Authentifizierung. Wie kommen die Schlssel dort hin, und wie werden sie gendert? Der IPSec-Standard erlaubt unter anderem die Mglichkeit, dies manuell zu tun. Manuelle Verfahren oder die bertragung ber ein anderes Medium sind aber, vor allem in groen Netzen, nicht praktikabel und oft unsicher. Die Lsung in IPSec ist ein spezielles Protokoll, das ber ein unsicheres bertragungsmedium, in der Regel die zu verwendende bertragungsstrecke selbst, mit Hilfe eines so genannten asymmetrischen Verschlsselungsverfahrens die bentigten Schlssel bertrgt beziehungsweise erzeugt. Dieses Protokoll, IKE (Internet Key Exchange), erledigt nicht nur das Schlsselmanagement, sondern auch die Aushandlung und Konfiguration der IPSec-Sicherheitsassoziation und deren Authentifizierung. Schutz vor Denial-of-Service-Angriffen in IPSec In IPSec wurden neben diesen Diensten auch Verfahren und Protokolle zum Schutz vor einer ganzen Reihe von Angriffen implementiert, die sich gegen das IPSec-System selbst oder das dahinter verborgene Netzwerk richten. Diese Manahmen sind sowohl in den IPSec-Sicherheitsprotokollen als auch im IKE-Protokoll zu finden und schtzen vor Denial-of-Service-Angriffen, vor Angriffen durch wiederholtes Senden (Replay-Angriffen) und vor so genannten Man-in-the-Middle-Angriffen, in denen sich ein Angreifer unbemerkt in eine Verbindung einschaltet und diese abhrt oder modifiziert. Auch hier wurde durch eine konsequente Standardisierung erreicht, dass diese Funktionen in einem Mindestumfang zwischen jedem IPSec-System vereinbar sind.
94
4.1.5
Beim Einsatz von Remote-Access-VPNs oder generell von VPNs, an denen Endgerte wie PCs oder Workstations als Einzelbenutzersystem teilnehmen, ist eine Authentifizierung der Benutzer notwendig. Auf die heute eingesetzten Technologien wird in Kapitel 5 detailliert eingegangen. An dieser Stelle sei darauf hingewiesen, dass in IPSec nur eine Authentifizierung auf Netzwerkebene stattfindet. Es identifizieren sich also nur die IP-Systeme, nicht die Benutzer oder Applikationen, die diese Systeme zur Kommunikation benutzen. Der Benutzer muss sich also getrennt davon authentifizieren, oder die beiden Authentifizierungen mssen auf eine Art und Weise, die auerhalb des Definitionsbereichs von IPSec liegt, miteinander kombiniert werden.
4.2
Die Kryptologie ist heutzutage ein Teilbereich der theoretischen Mathematik. Sie besteht aus der Kryptographie, die die Vertraulichkeit von Nachrichten gewhrleisten soll, und der Kryptoanalyse, der Kunst, eine verschlsselte Nachricht wieder lesbar zu machen. Obwohl man oft den Begriff der Verschlsselung mit Kryptographie gleichsetzt, kann man auch mit anderen Verfahren, z.B. der Verschleierung, den Inhalt von Nachrichten vor Unbefugten schtzen.
4.2.1
Geschichtliches
Die Kryptographie war schon immer eng mit dem militrischen Bereich verknpft. Hier entstand erstmals der Bedarf an ffentlicher bertragung geheimer Daten. Bereits aus dem Altertum gibt es hierzu die ersten berlieferungen, vorwiegend ber Methoden zur Verschleierung sowie ber einfache Substitutions- oder Transpositionsverfahren. Im letzten Jahrhundert, dem Jahrhundert der Weltkriege, wurde die Kryptographie fast ganz vom Militr und von Regierungsbehrden vereinnahmt. Erst in den letzten 30 Jahren wurde sie wieder ein mehr und mehr ffentliches Thema, vor allem bedingt durch die Zunahme der Datenkommunikation ber ffentliche Netzwerke (Internet, E-Commerce, Home-Banking usw.) und dem daraus resultierenden Wunsch nach Datenschutz und Datensicherheit. Allerdings ben die Nachrichtendienste dieser Welt immer noch einen starken Einfluss aus, der sich auch vielfach in staatlichen Regulierungen niederschlgt. In einigen Lndern ist sogar die private Datenverschlsselung bei Todesstrafe untersagt, zivilisiertere Lnder begngen sich mit Einfuhrverboten (Frankreich) von starker Verschlsselung durch Privatpersonen oder Firmen oder beschrnkten lange Zeit den freien Export (USA) von Kryptosystemen.
95
Insbesondere die US-amerikanische National Security Agency (NSA), die bis Mitte der 70er Jahre ihre Existenz rundweg ableugnete, obwohl sie jhrlich Milliardenbudgets verschlang und einige tausend der besten Mathematiker beschftigte, wird gern als der bse Bube vom Dienst hingestellt. Tatsache ist, dass ihr Auftrag im weltweiten Abhren und Entschlsseln von Informationsbermittlungen besteht, um amerikanische Interessen zu schtzen. Die Dehnbarkeit dieses Begriffes demonstrierte der ehemalige CIA-Direktor James Woolsey im Mrz 2000, als er in einem Interview in der Washington Post ganz offen zugab, dass bestimmte Informationen aus Abhrmanahmen der NSA an US-Firmen weitergegeben wurden um amerikanische Firmen vor der national culture of bribery (nationale Bestechungskultur) der europischen Konkurrenz zu schtzen, wie er sich ausdrckte. Manch andere, vor allem die Opfer in Europa, werden so etwas allerdings richtigerweise als Industriespionage bezeichnen. In der Tat haben die erfreulichen weltpolitischen nderungen der letzten Jahrzehnte die Geheimdienstler dieser Welt nicht etwa arbeitslos gemacht. Deren neue Hauptaufgabe, zumindest in den Industrienationen, besteht mittlerweile in der Industriespionage. Die Basis dieser Aktivitten bildet das US-amerikanische ECHELON-System, das unter aktiver Mitwirkung von Grobritannien und Australien aktiv alles an Kommunikationsmedien abhrt, was technisch mglich ist. Und das ist leider nicht wenig. Der Kern des Systems sind Rechnersysteme, die die ausspionierten Informationen auf bestimmte, fr die NSA interessant erscheinende Schlsselbegriffe absuchen. Wenn jemand die Rechner der NSA zu umfangreichen Berechnungen veranlassen mchte, dann braucht er einfach nur eine mit dem E-Mail-Verschlsselungsprogramm PGP verschlsselte sinnlose E-Mail in die USA zu schicken und im Betreff-Feld die Begriffe Airbus und Boeing einzutragen. Es reicht aber auch vermutlich schon aus, diese beiden Worte in einem Inlands-Telefongesprch fallen zu lassen die NSA betreibt im bayrischen Bad Aibling bisher ungehindert und unkontrolliert eine groe, offenbar gut ausgestattete Abhrstation! Bei rechtem Licht besehen, ist die NSA aber nicht mehr oder weniger bse als andere Geheimdienste auch, sie ist aufgrund ihrer Ressourcen nur leistungsfhiger und damit als gefhrlicher einzustufen. Das wirkliche Problem fr jemanden, der sich vor Aussphung durch die NSA schtzen muss, ist die Frage, was die NSA wirklich zu leisten vermag, welche Ressourcen und welchen Wissens- und Technologievorsprung sie tatschlich hat. Diese Frage ist bislang ungeklrt und gibt dadurch Anlass fr wste Spekulationen und Verschwrungstheorien. Andererseits sollte man sich im Bereich der Daten- und Netzwerk-Sicherheit ruhig eine Portion kontrollierten Verfolgungswahns gnnen, denn wer sagt Mein Netzwerk ist sicher, der hat schon verloren. Im letzten Jahrhundert gab es in der Kryptographie dramatische Entwicklungen. Es wurden zum ersten Mal in groem Stil Maschinen zum Verschlsseln und auf der Gegenseite zum Brechen der Codes eingesetzt. Dies war weniger
96
eine Neuerung im Grundlagenbereich, sondern es wurden zum ersten Mal in der Geschichte durch Automaten Geheimtexte erzeugt, die von Menschen nicht mehr zu brechen waren. Dies gelang nur noch mit Automaten mit wesentlich hherer Leistungsfhigkeit als mit der der Chiffriermaschinen. Der Auslser fr diese Entwicklungen waren die neuen Kommunikationstechnologien, die Nachrichten per Kabel oder Funk bertrugen und dadurch nicht mehr abhrsicher waren. Anfangs verbreiteten sich mechanische Systeme, gefolgt von elektromechanischen Rotormaschinen in den beiden Weltkriegen. Spter, ab Ende der 70er Jahre waren es rein elektronische Systeme, und heute befassen sich ausschlielich Computer mit der Arbeit der Kryptographie und Kryptoanalyse. Die elektromechanischen Rotormaschinen (z.B. die deutsche Enigma) produzierten bereits Chiffretexte, die von Menschen, selbst mit hchstem Personenund Zeitaufwand, nicht mehr zu entschlsseln waren. Zur Entschlsselung wurden erstmalig in der Geschichte in England elektronische Rechenmaschinen, die so genannten Bombs eingesetzt, die aus einer Vielzahl von Tyratronen, speziellen Schalter-Rhren, aufgebaut waren. Diese Vorlufer heutiger Computer waren schlielich in der Lage, die Chiffretexte der relativ einfach aufgebauten und vielleicht gerade dadurch sehr sicheren deutschen Enigma mit Known-Plaintext- und Chosen-Plaintext-Angriffen zu entschlsseln. Interessanterweise werden die Grundfunktionen der Enigma, die polyalphabetische Substitution und Permutation, auch heute noch in sehr vielen Neuentwicklungen von Verschlsselungsverfahren eingesetzt.
4.2.2
Die Kryptographie wird benutzt, um einen bestimmten Grad an Vertraulichkeit von ffentlich zugnglichen Informationen zu erreichen. Die Information darf nur den dazu Berechtigten, im Falle der Datenkommunikation dem Sender und Empfnger, im Klartext zur Verfgung stehen. Whrend sie zwischen Sender und Empfnger transportiert wird, muss die Information in einer Weise verndert sein, die es Dritten unmglich macht, Art und Inhalt der Information zurckzugewinnen.
4.2.3
Verschleierung und Verschlsselung
Als Methoden bieten sich grundstzlich zwei Verfahren an, die sich aufgrund ihres mglichen Einsatzbereiches unterscheiden. Die Verschleierung und die Verschlsselung von Informationen. Die Verschleierung wird nur noch selten eingesetzt, da ihre kryptographische Strke nicht sehr hoch und sie in greren Umgebungen mit sehr vielen Beteiligten nicht zu handhaben oder sehr unsicher ist. Im militrischen Bereich wird sie gelegentlich noch benutzt, um
97
taktische Informationen begrenzter Lebensdauer und mit eingeschrnktem Gltigkeitsbereich zu bertragen. Typischerweise werden hier Begriffe durch andere Begriffe ersetzt, um die Bedeutung von Informationen, die zum Beispiel durch Sprechfunkverkehr bertragen werden, zu verschleiern. Ein Beispiel aus der Datenkommunikation ist das bertragen von vertraulichen Informationen innerhalb anderer, auf den ersten Blick unverdchtiger Informationen. Zum Beispiel kann man die niederwertigen Bits einer Bilddatei benutzen, um darin Informationen verschleiert zu bertragen. Jemand, der die bertragung mitschneidet oder sich die Datei verschafft, bekommt nur ein Bild angezeigt, und selbst der augenscheinliche Vergleich mit dem Originalbild zeigt im Allgemeinen keinen Unterschied. Jedoch wrde ein strenger Vergleich der Bild-Dateien die Unterschiede an den Tag bringen.
Klartext Nachricht
Sender
Empfnger
Mitlesen der Nachricht
Verndern der Nachricht
Angreifer
Sender
Angreifer
Kein Mitlesen Keine Vernderung
Empfnger
Nachricht
Nachricht
Nachricht
Verschlsselung
Chiffretext
Entschlsselung
Abbildung 4.1: Durch Verschlsselung wird eine Nachricht fr Dritte unlesbar.
Die Verschlsselung ist meist universeller angelegt, in der Regel sind die Verschlsselungsverfahren selbst sogar offen gelegt. Die Sicherheit wird durch eine Zusatzinformation, den so genannten Schlssel, erreicht, der neben dem
98
Klartext als zweite Eingangsgre den Chiffretext erzeugt. Mit Hilfe dieses Schlssels knnen Sender und Empfnger die zwischen ihnen ausgetauschten Informationen verund entschlsseln. Die Verschlsselungsverfahren, die heute in der Datenkommunikation Anwendung finden, sind sehr universell angelegt und arbeiten nicht mehr wie die Verschleierung auf der Ebene von Sprachbegriffen, sondern auf der Ebene von abstrakten Informationseinheiten wie elektrischen Spannungspegeln, Bits, Bytes usw.
4.2.4
Die Kunst der Kryptoanalyse
Die Kryptoanalyse ist die Kunst, eine verschlsselte Nachricht wieder lesbar zu machen. Dies ist leichter gesagt als getan. Denn sie ist in der Tat eine Kunst oder genau genommen ein Beweis menschlicher Erfindungsgabe und Fantasie. Es gibt eine ganze Reihe verschiedener Angriffsarten, die sich darin unterscheiden, welche Informationen und Mglichkeiten dem Kryptoanalytiker zur Verfgung stehen. Unter der Krytoanalyse versteht man im Allgemeinen nicht das Erzeugen des Klartextes aus dem Chiffretext, sondern das Auffinden des zur Verschlsselung verwendeten Schlssels. Alle heutigen Chiffrierverfahren benutzen praktisch allgemein bekannte, offen gelegte Algorithmen, deren Sicherheit darauf basiert, dass der Schlssel zum Ver- und Entschlsseln geheim gehalten wird. Die Sicherheit dieser Verfahren basiert also ausschlielich auf dem Schlssel, der damit auch zum Hauptangriffsziel der Kryptoanalytiker avanciert. Ciphertext-Only-Angriff Dies ist die grte Herausforderung an einen Kryptoanalytiker. Es steht ihm nur der Chiffretext zur Verfgung, und er kennt weder die Art noch den Inhalt auch nur von Teilen des Klartexts. Das Hauptproblem dieses Angriffs ist die Tatsache, dass der Angreifer gar nicht wei, wann er einen Teil des Chiffretexts entschlsselt hat, da er ja keinerlei Kenntnis vom Klartext hat. Known-Plaintext-Angriff (Brute-Force-Angriff) Besser hat es ein Kryptoanalytiker schon, wenn er zum Chiffretext wenigstens einen Teil des zugehrigen Klartextes kennt, also auch wei, wann der den richtigen Schlssel gefunden hat. Der Brute-Force-Angriff, also ein Angriff mit Brachialgewalt, ist der typische Vertreter dieser Angriffsart. Man probiert am Chiffretext mit dem bekannten Dechiffrieralgorithmus so lange alle in Frage kommenden Schlsselvarianten aus, bis man den richtigen gefunden hat. Dies ist der Fall, wenn das Ergebnis der Entschlsselung gleich dem bekannten Klartext ist.
99
Der folgende Pseudocode demonstriert einen Brute-Force-Angriff auf eine DES-Verschlsselung. Die Funktion bekommt als Eingangsparameter den Chiffretext und den Klartext und liefert als Ergebnis den Schlssel zurck. Qword sind 64 Bit groe Variablen. Die externe Funktion DES entschlsselt den Ciphertext mit dem key und liefert als Ergebnis einen 64-Bit-String zurck:
Function Qword Brute_Force_Attack(Qword Cleartext, Qword Ciphertext) Extern Qword DES_Decrypt(Qwod key,Qword Ciphertext); Qword key; For key = 0 to 72057594037927936 do IF Cleartext == DES_Decrypt(key,Ciphertext) then Return(key) done Return(0)
Wie man leicht erkennen kann, ist das Hauptproblem dieses Verfahrens die Zeit, die fr die Suche aufgewendet werden muss. Nehmen wir einmal ein Beispiel aus der Praxis. Der Data Encryption Standard benutzt einen Schlssel, der 56 Bit lang ist, also insgesamt 72.057.594.037.927.936 verschiedene Werte annehmen kann. Angenommen, ein sehr schneller Rechner bruchte fr jede Dechiffrierung eine Mikrosekunde und der Schlssel wrde statistisch gesehen nach 50% aller Versuche gefunden, dann wrde solch ein Angriff immer noch ber 1.142 Jahre dauern und wre praktisch sinnlos. Der Klartext zu einem gegebenen Chiffretext ist sehr oft bekannt, da darf man sich keine Illusionen machen. Bestimmte Datei-Header, Floskeln im Text, Mail-Signaturen usw. sind immer gleich und dadurch auch leicht zu erraten. Es werden auch sehr oft Block-Verschlsselungsverfahren eingesetzt, die den letzten Block nach einem allgemein bekannten Verfahren mit Fllzeichen (Padding) auffllen. Das Verhltnis der Schnelligkeit eines Brute-Force-Angriffs zum vorhandenen Budget hierfr ist innerhalb bestimmter technischer Grenzen annhernd linear. In realen Systemen zur Kryptoanalyse von DES arbeiten viele DES-Prozesse parallel mit eigenen Teilbereichen des zu durchsuchenden Schlsselraumes. Entweder verwendet man Parallelrechner oder spezielle Systeme mit insgesamt Hunderten oder Tausenden parallel arbeitender DES-Chips, die einen 56 Bit langen Schlssel innerhalb von Stunden oder gar Minuten knacken knnen. Der NSA unterstellt man, mittlerweile weniger als eine Sekunde zu bentigen, um eine 56-Bit-DES-Verschlsselung zu brechen. Schutz gegen einen Brute-Force-Angriff erzielt man ganz einfach durch Verlngern des Schlssels, denn jedes Bit mehr Schlssellnge verdoppelt die Suchzeit. Der Brute-Force-Angriff ist aber letztendlich auch die Messlatte fr die Sicherheit eines Verschlsselungsalgorithmus. Ein Verschlsselungsverfahren gilt definitionsgem dann als sicher, wenn der Brute-Force-Angriff die schnellste bekannte Methode ist, den Schlssel zu ermitteln. Damit kann man auch seine
100
bentigte Schlssellnge kalkulieren, indem man den Aufwand eines mglichen Angriffs abschtzt und als Resultat seine Schlssel, natrlich mit einer krftigen Sicherheitsreserve versehen, hinreichend lang macht. Chosen-Plaintext-Angriff und Adaptive-Chosen-Plaintext-Angriff Beim Chosen-Plaintext-Angriff kann der Kryptoanalytiker selbst Klartext in die Verschlsselung einschleusen, und beim Adaptive-Chosen-PlaintextAngriff kann er dies sogar in einer Schleife mit immer neuem Klartext tun, abhngig vom Ergebnis der Chiffrierung. Diese beiden Angriffe sind, vor allem im letzteren Fall eher eine Angelegenheit frs Labor. Genau dort werden diese Verfahren auch eingesetzt, und zwar um Verschlsselungsverfahren auf ihre Strke zu testen. Ein in letzter Zeit populr gewordener Vertreter dieser Angriffsart ist die differenzielle Kryptoanalyse, mit der man zum Beispiel DES, zumindest theoretisch, analysieren konnte. Das Ziel dieses Verfahrens ist festzustellen, wie sich der Chiffretext bei gezielten nderungen des Klartextes ndert, um so auf den Schlssel zu schlieen. Dies sind bisher jedoch alles theoretische Angriffe, die obendrein recht futuristisch anmutende Computer mit 1000 Terabyte RAM und noch viel grere Massenspeicher voraussetzen. Auerdem ist die Komplexitt einer differenziellen Kryptoanalyse immer noch grer als die eines Brute-Force-Angriffs. Die weiteren Rahmenbedingungen zu diesem Verfahren sind darber hinaus vllig unrealistisch, es mssen zum Beispiel zu einem bestimmten Schlssel 1012 Gbyte Chiffretext und der dazugehrige Klartext bekannt sein, um ihn zu berechnen. Dies kommt in der Praxis uerst selten vor, und es lsst sich mit modernen Sicherheitsprotokollen, wie zum Beispiel IPSec und IKE, auch wirksam verhindern, dass mit einem einzigen Schlssel berhaupt so viele Daten verschlsselt werden.
4.2.5
Einfhrung in die Kryptographie
Grundbausteine der Kryptographie Das Grundgerst der Kryptographie ist eine mglichst starke Kombination von Diffusion und Konfusion. Die Diffusion verschleiert gewissermaen den Zusammenhang zwischen den Informationselementen im Klartext und Chiffretext. Die Konfusion verteilt die Informationselemente des Klartextes im Chiffretext. Oder sie verstrkt hier haben wir dann unsere Kombination beider Prinzipien die Diffusion dadurch, dass die Informationselemente im Chiffretext umverteilt werden. Das klingt noch etwas abstrakt, ist aber, wie Sie anschlieend sehen werden, mit einfachen Verfahren zu realisieren. Die Diffusion wird in der Praxis durch Substitution und die Konfusion durch Permutation oder Transposition realisiert.
101
Substitution Bei der Substitutionschiffrierung wird jedes Zeichen im Klartext durch ein anderes Zeichen im Chiffretext ersetzt. Die Zeichen des Klartexts tauchen nicht mehr im Chiffretext auf. Die Zuordnungsvorschrift der Zeichen, also der Schlssel, ist nur den Berechtigten, dem Sender und dem Empfnger bekannt. Man unterscheidet unterschiedliche Substitutionsmethoden. Bei der monoalphabetischen Substitution wird jedes mgliche Zeichen des Klartexts durch ein einziges, fest zugeordnetes Zeichen ersetzt. Abbildung 4.2 zeigt ein Beispiel fr eine monoalphabetische Substitution. Der ASCII-Text WISSEN IST MACHT wird entsprechend der angegebenen Substitutionstabelle sie stellt den Schlssel dieses Verfahrens dar in den Chiffretext XZ66BPQZ6SQ5FOVS transformiert.
Klartext WISSEN IST MACHT
Verschlsselung
Schlssel A C E I M N T W Leer H S . .... F O B Z 5 P S X Q V 6 . ....
Substitution
Chiffretext XZ66BPQZ6SQ5FOVS
Entschlsselung Substitution
Abbildung 4.2: Eine monoalphabetische Text-Substitutionschiffrierung
Bei der polyalphabetischen Substitution kann jedes mgliche Zeichen des Klartexts durch verschiedene Zeichen im Chiffretext ersetzt werden, zum Beispiel kann A zu X, R oder Z werden, je nachdem, an welcher Stelle es im Klartext vorkommt. Dieses Verfahren fand auch in der bekannten deutschen Schlsselmaschine Enigma erfolgreich Anwendung. Die Nachteile der monoalphabetischen Substitution lassen sich aus dem Chiffretext in Abbildung 4.2 ablesen. Aufgrund der festen Zuordnung zueinander, tauchen bestimmte Zeichen mehrfach auf. Beispielsweise erscheint die Ziffer 6 dreimal in der kurzen Zeile, dabei zweimal hintereinander; der Buchstabe Q kommt zweimal vor. Ein gebter Angreifer erkennt daraus sofort Folgendes:
102
Es handelt sich hier um die Verschlsselung eines ASCII-Textes, die Doppelzeichen mssen auch Doppelbuchstaben im Klartext sein, und die hufig auftauchenden Zeichen sind entweder Leerzeichen im Klartext oder es sind Buchstaben, die in einer bestimmten Sprache oft vorkommen. Dadurch, dass durch die monoalphabetische Substitution die Hufigkeit und die Position der im Klartext vorkommenden Zeichen im Chiffretext nicht verndert, lsst sich eine solche Chiffrierung leicht knacken, sogar durch einen Ciphertext-Only-Angriff. Diesen Nachteil umgeht die polyalphabetische Substitution, indem dort ein Eingangswert im Klartext mehrere verschiedene Ausgangswerte im Chiffretext zur Folge haben kann.
3 Bit Eingabe, N M=S(N)
N M = = = = = = = =
Spaltenadressierung
Zeilenadressierung
11 11
10 11
00 10
01 00
0 1 2 3 4 5 6 7
3 2 0 1 3 3 2 0
N=S(N)
M N = = = = 2,7 3 1,6 0,4,5 0 1 2 3
Nichtlineare S-Box
2 Bit Ausgabe, M
Abbildung 4.3: Die nichtlineare S-Box substituiert unumkehrbar binre Informationsgren.
In modernen Hard- und Software-Implementierungen erfolgt die Substitution mit Hilfe so genannter S-Boxen (Substitution box). Eine S-Box liefert zu einem Eingangswert N einen Ausgangswert M. Der Wertebereich von N kann kleiner oder gleich dem von M sein, im ersten Fall handelt es sich um eine lineare, im zweiten um eine nichtlineare S-Box. Kryptographisch interessant ist die nichtlineare Substitution, weil hier verschiedene Zeichen des Klartexts auf ein Zeichen Chiffretext abgebildet werden, so dass nicht mehr zurckverfolgbar ist, welcher Eingabewert fr einen bestimmten Ausgabewert verantwortlich war. Damit hat man bereits eine, wenngleich noch schwache, Einwegfunktionalitt realisiert.
103
Die nichtlineare S-Box in Abbildung 4.3 transformiert den 3-Bit-Eingabewert N in den 2-Bit-Ausgabewert M. Der Ausgabewert 0 beispielsweise kann zwei mgliche, der Ausgabewert 3 bereits drei mgliche Eingangswerte gehabt haben. In der Praxis werden mehrere verschiedene S-Boxen so lange kaskadiert, bis eine Rckverfolgung des Eingangswertes aus dem Ausgangswert nicht mehr mglich ist. Damit erzielt man eine Einwegfunktionalitt und kann den Ausgangswert nicht mehr zurckberechnen, auch nicht, wenn man die internen Tabellen der S-Box(en) kennt. Es ist offensichtlich, dass man solch ein Konstrukt zwar zum Verschlsseln, aber nicht mehr zum Entschlsseln benutzen kann. In der Praxis dienen solche Funktionen, also nichtlineare S-Boxen in Verbindung mit Permutationen, auch nicht zum eigentlichen Verschlsseln, sondern zur Transformation von Schlsseln. Permutation (Transposition) Bei der Transpositionschiffrierung werden alle Zeichen des Klartextes auf andere Positionen im Chiffretext umgesetzt. Die Zeichen des Originaltextes bleiben im Chiffretext erhalten. Die Art der Transposition, d.h. der Schlssel, ist nur den Berechtigten, also dem Sender und dem Empfnger, bekannt. Je geringer der Informationsgehalt der Zeichen ist, die permutiert werden sollen, desto strker ist dieses Verfahren. Eine Permutation von Wrtern einer Sprache ist leicht zu analysieren, die von reinen Buchstaben schon weniger leicht, aber Permutationen auf Bit-Ebene sind nur sehr schwer zurckzuverfolgen.
Spaltentransposition W
_
I
I
S
S
H
S
T
E _
_
N M
_
Chiffretext W_AIICSSHSTTE__NM_
Abbildung 4.4: Eine Spaltentransposition vertauscht die ursprnglichen Positionen der Zeichen.
Abbildung 4.4 zeigt ein Beispiel fr eine Transpositionschiffrierung, die so genannte Spaltentransposition. Hierbei wird der Klartext WISSEN IST MACHT zeilenweise so lange in eine Matrix eingetragen, bis der Text zu Ende ist. Der Chiffretext wird durch ein anschlieendes spaltenweises Auslesen der Tabelle erzeugt.
104
Zur Transposition werden in modernen, praktischen Implementierungen so genannte P-Boxen (Permutation box) eingesetzt. Der Ausgangswert einer P-Box entsteht aus einer bitweisen Vertauschung der Bits des Eingangswerts. P-Boxen knnen wie S-Boxen in Hard- und Software realisiert werden. Bei Hardware-Implementierungen kann die Permutation durch eine Festverdrahtung mit extrem hohen Geschwindigkeiten realisiert werden. Wie bei der Substitution gibt es hier ebenfalls lineare und nichtlineare Varianten der P-Boxen. Lineare P-Boxen mit einer festen Zuordnung sind kryptographisch wenig interessant. In der Praxis kommen in der Regel nichtlineare P-Boxen vor, die eine so genannte Kompressions- oder Expansionspermutation durchfhren. Bei der Expansionspermutation ist die Anzahl der Bits des Ausgangswerts grer als die des Eingangswerts. Bei der Kompressionspermutation ist die Anzahl der Bits des Ausgangswerts kleiner als die des Eingangswerts, hierbei gehen Informationen verloren.
Nichtlineare P-Box (Expansionssubstitution) LSB
6 Bit Eingabe, N
LSB
MSB MSB
Abbildung 4.5: Die Expansionspermutation erzeugt einen Lawineneffekt.
Abbildung 4.5 zeigt ein Beispiel einer nichtlinearen P-Box. Es handelt sich um eine Expansionspermutation mit einem 6-Bit-Eingangswert N und einem 8-Bit-Ausgangswert M. Um den 8-Bit-Ausgangswert zu erhalten, werden jeweils 2 Bit des Eingangswerts verdoppelt. Die nderung eines einzigen Bits dieser beiden hat eine nderung von gleich zwei hherwertigen Bits des Ausgangswerts zur Folge. Das heit, durch minimale nderungen des Eingangswerts lassen sich starke nderungen des Ausgangswertes erzielen. Man spricht hierbei vom einem so genannten Lawineneffekt. Um eine Dechiffrierung zu erschweren, werden in der Praxis Substitutionsund Permutationsverfahren miteinander verknpft und hinreichend oft kaskadiert, um an einem bestimmten Punkt einen Zustand zu haben, an dem von dem Ausgangswert nicht mehr auf den Eingangswert geschlossen werden kann. Eine solche Produktchiffre sehen Sie in Abbildung 4.6: Hier werden
8 Bit Ausgabe, M
105
nichtlineare Substitutionen und Expansionspermutationen so lange verkettet, bis ein Ausgangswert entstanden ist, aus dem der Ursprungswert nicht mehr zurckberechnet werden kann.
Nichtlineare Substitution
Expansionspermutation
Abbildung 4.6: Eine Produktchiffre verkettet Substitutionen und Permutationen.
Feistel-Netzwerke Feistel-Netzwerke sind der Grundbaustein fast aller heute gebruchlichen symmetrischen Block-Verschlsselungsverfahren. Der Name stammt von dem damaligen IBM-Mitarbeiter Horst Feistel, der sich Anfang der 70er Jahre fr seinen Arbeitgeber mit der Entwicklung von Chiffrierverfahren beschftigte. Aus seinem Team stammt auch der Lucifer-Chiffre, ein Algorithmus, der spter nach einigen Modifikationen zum Data Encryption Standard (DES) wurde und auch heute noch weltweit in Gebrauch ist. Auf den ersten Blick sieht ein Feistel-Netzwerk oder ein Feistel-Zyklus, der aus zwei so genannten Runden eines Feistel-Netzwerks besteht, gar nicht so aufregend aus. Aber es besticht durch eine Eigenschaft, die es zur Basisstruktur moderner BlockChiffrierverfahren gemacht hat. Es erlaubt nmlich, die unumkehrbaren Produktchiffren, die aus nichtlinearen Substitutionen und Permutationen bestehen, sowohl zur Ver- als auch zur Entschlsselung zu benutzen! In Abbildung 4.7 ist ein Feistel-Zyklus dargestellt, der aus zwei Runden eines Feistel-Netzwerks besteht. Die Funktion F ist eine Produktchiffre, die auf unumkehrbare Weise aus ihren Eingangswerten dem Teilschlssel und einer Hlfte des Klartextes ihren Ausgangswert erzeugt. Die eigentliche Transformation der anderen Hlfte des Klartextes in den Chiffretext erfolgt jedoch und das ist der springende Punkt in diesem Verfahren durch eine einfache Exklusiv-Oder-Verknpfung. Und diese Funktion, Exklusiv-Oder, ist umkehrbar, denn man kann den Chiffretext mit dem gleichen Schlssel, mit dem er erzeugt wurde, wieder in den ursprnglichen Klartext umwandeln. Auf unser Beispiel bezogen folgt somit, dass bei Kenntnis der Funktion F und des Schls-
106
sels, aus dem die Teilschlssel abgeleitet werden, eine Dechiffrierung dadurch mglich ist, dass man den Chiffretext in den Feistel-Zyklus einspeist und lediglich die Reihenfolge der zu benutzenden Teilschlssel umkehrt. Das Ergebnis ist wieder der Klartext. In unserem Beispiel wrde nach einem Zyklus aus dem Klartext (Li,Ri) der Chiffretext (Li+2,Ri+2) durch folgende Transformationen: Erste Runde (die Exklusiv-Oder-Verknpfung ist im Folgenden mit notiert): Li+1 = Ri Ri+1 = Li F(Ri,Ki) Zweite Runde: Li+2 = Ri+1 Ri+2 = Li+1 F(Ri+1,Ki+1) Durch die Umkehrung, also wenn dieser Zyklus mit dem Chiffretext (Li+2,Ri+2) und dem Teilschlssel Ki+1 beginnt, erhalten wir wieder den Klartext (Li,Ri): Erste Runde: Li+1 = Ri+2 Ri+1 = Li+2 F(Ri+2,Ki+1) Zweite Runde: Li = Ri+1 Ri = Li+1 F(Ri+1,Ki) Des Weiteren folgt daraus auch, dass es eine entsprechend unumkehrbare Funktion F vorausgesetzt nicht mehr mglich ist, auch bei Kenntnis von zusammengehrendem Klar- und Chiffretext, einen oder mehrere Teilschlssel zu rekonstruieren. Die einzig verbliebene Angriffsart ist somit ein BruteForce-Angriff. Praktische Implementierungen begngen sich nicht mit nur einem FeistelZyklus, sondern verketten ihn zu mehreren Runden. DES benutzt zum Beispiel acht Zyklen, also insgesamt 16 Runden. Die zu verwendende Anzahl der Runden hngt mageblich von der Qualitt der Funktion F ab, die als einzige ber die Sicherheit des Chiffriererfahrens entscheidet.
107
Li
Ri
Klartext
Teilschlssel 1 1. Runde
F(Ri,Ki)
Ki
1 Zyklus
Li+1
Ri+1
Teilschlssel 2
2. Runde
F(Ri+1,Ki+1)
Ki+1
Li+2
Ri+2
Li+N
Ri+N
Chiffretext
Abbildung 4.7: Ein Feistel-Zyklus, bestehend aus zwei Runden eines Feistel-Netzwerks
4.2.6
Verschlsselungsverfahren
Alle in der Praxis eingesetzten Verschlsselungsverfahren benutzen einen allgemein bekannten Algorithmus, der den Chiffretext aus dem Klartext und aus einem Schlssel erzeugt. Die Sicherheit dieser Verfahren basiert damit ausschlielich auf der Geheimhaltung und der Qualitt des Schlssels, nicht auf der Vertraulichkeit des Algorithmus selbst. Aus diesem Grunde sind auch alle ernst zu nehmenden Algorithmen offen gelegt. Dies bedeutet, dass jeder diese Algorithmen analysieren und auf Schwachstellen testen kann und somit unsichere Kandidaten sehr schnell entdeckt werden. So gibt es vermutlich kein Verfahren, an dessen Kryptoanalyse sich mehr Personen und Organisationen versucht haben, als an DES und Triple-DES. Die Tatsache, dass es noch keiner geknackt hat, also noch niemand ein Verfahren angewendet hat, das schneller als ein Brute-Force-Angriff ist, spricht letztendlich fr dessen Sicherheit.
108
Es gibt zwei grundstzlich verschiedene Verfahren, die auf Schlsseln basieren: Die symmetrische oder Secret-Key-Verschlsselung und die asymmetrische oder Public-Key-Verschlsselung. Symmetrische Verschlsselung Bei der symmetrischen Verschlsselung kennen alle beteiligten Gegenstellen einen geheimen Schlssel, den so genannten Secret Key, der sowohl zum Verals auch zum Entschlsseln benutzt wird. Symmetrische Verfahren werden in Form von Datenstrom- oder Datenblock-Verschlsselungen verwendet. Das Grundprinzip funktioniert, wie in Abbildung 4.8 dargestellt. Zunchst vereinbaren Sender und Empfnger einen gemeinsamen Schlssel. Dieser dient dem Sender zur Verschlsselung des Klartexts und dem Empfnger zur Entschlsselung des Chiffretexts.
Klartext
WISSEN IST MACHT
Klartext
WISSEN IST MACHT
Symmetrischer Schlssel
Verschlsselung
Chiffretext
P/h9?fa4Hfd$lGfa50he6s
Entschlsselung
Abbildung 4.8: Eine symmetrische Verschlsselung
ltere Algorithmen wurden in der Regel zur Implementierung in Hardware entwickelt, neuere Verfahren wurden universeller ausgelegt und erreichen auch als Software-Implementierung eine hohe Performance. So gibt es heute bereits DES-Chips mit mehr als 1 Gbit/s Durchsatz. RC4, als Vertreter reiner Software-Verschlsselung, wurde speziell fr den Betrieb auf der 80x86-Prozessor-Serie der Firma Intel entwickelt und optimiert. Da die Sicherheit dieser Verfahren ausschlielich von der Lnge und der Vertraulichkeit des Schlssels abhngt, sind sie leicht an verschiedene Sicherheitsanforderungen anzupassen. Um sich vor einem Brute-Force-Angriff zu schtzen, gibt es verschiedene Empfehlungen, wie lang der Schlssel sein sollte, und zwar abhngig davon, von wem ein Angriff erwartet wird und wie lange Informationen geheim gehalten werden mssen. Allerdings sind solche
109
Empfehlungen mit einer gewissen Vorsicht zu genieen, denn wer kann heute schon sagen, welche Technologie in 20 Jahren zur Verfgung stehen wird. Zu diesem Zeitpunkt sind Daten, die heute mit einem jetzt noch sicheren Verfahren verschlsselt werden, vielleicht innerhalb von Stunden oder Minuten zu dechiffrieren.
Mgliche Kombinationen 1.000 8.1450.625 1.099.511.627.776 1.099.511.627.776 1.099.511.627.776 Testzeit 2s 1 s 1 s 1 s 1 s Parallele Tests 1 1 1 50 Mittlere Suchzeit 17 Minuten 40 Sekunden 6 Tage 2,8 Stunden
Schlsselart Kofferschloss Kurzes Passwort
Lnge 10 Bit 28 Bit
RC4-Schlssel 40 Bit RC4-Schlssel 40 Bit RC4-Schlssel 40 Bit DES-Schlssel 56 Bit DES-Schlssel 56 Bit IDEASchlssel IDEASchlssel
1.000.000 0,05 Sekunden 1 1 1.142 Jahre 5,4 * 1024 Jahre 1.000.000 10 Stunden
72.057.594.037.927.900 1 s 72.057.594.037.927.900 1 s 1 s 1 s
128 Bit 3,4 * 1038 128 Bit 3,4 * 1038
1.000.000 5,4 * 1018 Jahre
Tab. 4.1: Brute-Force-Angriffe auf verschieden lange Schlssel
In Tabelle 4.1 sehen Sie einen Vergleich zwischen Brute-Force-Angriffen auf Schlssel verschiedener Lnge. Als Zeitbedarf wurde eine Mikrosekunde pro Test angesetzt. Fr das RC4-Verfahren mit 40 Bit wirksamer Schlssellnge, wie es in praktisch allen Webbrowsern mit der (alten) US-Exportlizenz eingesetzt wird und mit dem somit auch Ihre Kreditkarteninformationen verschlsselt werden, sehen Sie in der Zeile 4, dass der Zeitaufwand fr einen Angriff mit 50 parallelen Systemen nur 2,8 Stunden betrgt. Das DES-Verfahren mit seiner Schlssellnge von 56 Bit beschftigt eine Workstation schon ber 1.000 Jahre falls der Rechner berhaupt so lange funktioniert und das Resultat dann noch jemanden interessiert. Ein Brute-Force-Angriff auf ein starkes Verschlsselungsverfahren mit 128-Bit-Schlssel wrde theoretisch 5,4 x 1024 Jahre dauern. Man kann den Aufwand zum Suchen eines Schlssels vergrern, indem man sehr viele, schnelle Hardwaresysteme parallel einsetzt und jedes nur einen Teilbereich des mglichen Schlsselraums durchsuchen lsst. Mit Investitionen im siebenstelligen Dollarbereich sind Systeme denkbar wer wei, vielleicht gibt es sie auch schon , die 1.000.000 Suchvorgnge pro Minute schaffen knnen. Der 56-Bit-DES-Schlssel wre mit einem
110
solchen System in 10 Stunden gefunden; der IDEA-Schlssel wre mit einer Suchzeit von 5,4 x 1018 Jahren immer noch sicher. Ein 40-Bit-Schlssel wre damit jedoch bereits im Schnitt nach 50, garantiert nach 100 Millisekunden gefunden! Anhand dieser Tabelle knnen Sie erkennen, dass Verschlsselungsverfahren mit einer Schlssellnge von 128 Bit oder grer, vor einem BruteForce-Angriff sicher sind. Selbst wenn sich in den nchsten zehn Jahren die Geschwindigkeit der Prozessoren um den Faktor 1.000.000.000 steigern sollte, betrge die Suchzeit immer noch 5,4 x 109 Jahre mit einem solchen Supercomputer. Asymmetrische Verschlsselung Im Gegensatz zur symmetrischen Verschlsselung verwenden die asymmetrischen Verfahren zwei verschiedene Schlssel. Auf der einen Seite ist dies der ffentliche Schlssel oder Public Key, den jeder kennt und der zum Verschlsseln (Chiffrierschlssel) einer Nachricht verwendet wird. Auf der anderen Seite gibt es einen geheimen Schlssel oder Private Key, den nur der Empfnger der Nachricht kennt und der zum Entschlsseln (Dechiffrierschlssel) dient. Eine mit einem ffentlichen Schlssel verschlsselte Nachricht kann mit demselben oder einem anderen ffentlichen Schlssel nicht mehr entschlsselt werden. Private Key und Public Key sind einander fest zugeordnete Schlsselpaare, die aus einem mathematischen Verfahren, das nicht zurckzuverfolgen ist, voneinander abgeleitet werden. Die bekanntesten Public-Key-Verfahren sind RSA und Diffie-Hellman, die spter in diesem Kapitel noch ausfhrlich besprochen werden. Abbildung 4.9 zeigt den Ablauf einer asymmetrischen Verschlsselung. Der Klartext wird mit dem ffentlichen Schlssel verschlsselt. Auf der Gegenstelle wird der Chiffretext mit dem privaten Schlssel entschlsselt. Der ffentliche Schlssel ist jedermann zugnglich. Er kann zum Beispiel auf einem ffentlichen Server abgelegt sein, da jede Person, die einer anderen Person nach diesem Prinzip eine Nachricht zusenden will, deren ffentlichen Schlssel zum Verschlsseln bentigt. Der Empfnger benutzt seinen privaten Schlssel, um die Nachricht wieder zu entschlsseln. Nur er allein kann die Nachricht entschlsseln, weil nur er seinen privaten Schlssel besitzt. Es gibt asymmetrische Verfahren, zum Beispiel RSA, die umgekehrt auch mit dem privaten Schlssel verschlsseln und mit dem ffentlichen Schlssel wieder entschlsseln knnen. Diese Betriebsart spielt zur Verschlsselung von Nachrichten keine Rolle, sondern wird fr Anwendungen zur Authentifizierung durch digitale Signaturen eingesetzt.
111
Klartext
WISSEN IST MACHT
Klartext
WISSEN IST MACHT
ffentlicher Schlssel
Privater Schlssel
Verschlsselung
Chiffretext
7245b0738cd6199a25f28
Entschlsselung
Abbildung 4.9: Die asymmetrische Verschlsselung benutzt zwei unterschiedliche Schlssel zur Ver- und Entschlsselung.
Auch bei asymmetrischen Algorithmen muss man sich vor Angriffen schtzen. Asymmetrische Verfahren arbeiten aus technischen Grnden allerdings mit weit greren Schlssellngen als symmetrische. Ein heute sicherer asymmetrischer RSA-Schlssel beginnt in der Regel bei einer Lnge von 1024 Bit. Deshalb gelten hier andere Werte zum Schutz vor Angriffen. Asymmetrische Verfahren sind wesentlich langsamer als symmetrische. Deshalb werden sie selten zur Verschlsselung von Nutzdaten, wie Datenpaketen und Dateien, eingesetzt. In der Praxis dienen sie dazu, ein symmetrisches Schlsselpaar fr den Sender und Empfnger zu erzeugen. Dieser Vorgang dauert mit einem 133-MHz-Pentium-PC kaum lnger als zwei bis drei Sekunden bei einem 2048 Bit groen Schlssel. Da sich keine nennenswerte Verzgerung ergibt, kann der Schlssel so gro wie mglich gewhlt werden. Dies ist auch aus einem anderen Grund empfehlenswert. Alle asymmetrischen Verfahren benutzen Algorithmen, die auf bestimmten, bisher als unlsbar geltenden mathematischen Problemen basieren. Es ist zwar sehr unwahrscheinlich, dass sie jemals vollstndig gelst werden, aber es knnen durchaus drastische Optimierungen eingefhrt werden. Das heit, dass zumindest theoretisch in Zukunft die Gefahr der Rckberechnung besteht, auch wenn der Aufwand heute noch im Bereich von mehreren Milliarden Jahren liegt. Auch hier gilt deshalb die gleiche Empfehlung wie bei symmetrischen Verfahren: Einen Schutz vor der Rckberechnung des Schlssels und vor Brute-Force-Angriffen bieten nur entsprechend groe Schlssellngen, die in Abhngigkeit davon zu whlen sind, welche Informationen wie lange geschtzt werden mssen. Generell sollte man seine Schlssellngen, sofern es das Verarbeitungsvermgen der eingesetzten Systeme und die verwendeten Algorithmen zulassen, mit einer krftigen Sicherheitsreserve versehen.
112
Symmetrische Verschlsselungsverfahren
4.3
Symmetrische Verschlsselungsverfahren
Die symmetrischen Verfahren verwenden in der Regel entweder die Datenblock- oder die Datenstrom-Verschlsselung. Bei einer Datenblock-Verschlsselung werden jeweils komplette Blcke einer bestimmten Gre mit einem Schlssel verschlsselt (siehe Abbildung 4.10). Beim bekanntesten Vertreter dieser Verfahren, dem Data Encryption Standard (DES), ist der Datenblock beispielsweise 64 Bit gro. Kleinere Blcke werden auf die bentigte Gre aufgefllt (Padding), um korrekt verarbeitet werden zu knnen.
Klartext
BLOCKCHIFFRE
Fllzeichengenerator
B lock 2
Block 1
BLOCKCHI
FFRE@@@@
Verschlsselung
Verschlsselung
Ff0d62723d8fe
7245b0738cd619
Chiffretext
Chiffretext
Abbildung 4.10: Eine Datenblock-Verschlsselung
Bei der Datenstrom-Verschlsselung (siehe Abbildung 4.11) wird ein Datenstrom, der aus Bits, Bytes oder anderen systemabhngigen Informationsgren besteht, so lange fortlaufend verschlsselt, bis der Eingangsdatenstrom vollstndig verarbeitet wurde. Die Datenstrom-Verschlsselung ist oft schneller als die Datenblock-Verschlsselung und hat eine geringere Latenz. Eine Schwachstelle der Datenblock-Verschlsselung ist das Padding, denn die Art und Weise, wie aufgefllt werden muss, muss sowohl dem Sender als auch dem Empfnger bekannt sein und ist sogar oft in Standards verffentlicht. Da man statistisch gesehen davon ausgehen kann, dass im Schnitt der letzte Block zu 50% aufgefllt wurde, bietet sich bei der Datenblock-Verschlsselung immer die Mglichkeit eines Know-Plain-Text-Angriffs. Deshalb sollte die reine Datenblock-Verschlsselung mglichst nie zur bertragung von sehr kurzen Nachrichten, zum Beispiel von Telnet- oder Terminal-Sessions, angewandt werden.
113
Klartext
BLOCKCHIFFRE
KlartextBytestrom Chiffretext
Verschlsselung
SchlsselBytestrom
Ff0d62723d8fe
Schlsselstromgenerator
Abbildung 4.11: Eine Datenstrom-Verschlsselung
Die Datenstrom-Verschlsselung liest den Eingangsdatenstrom und verschlsselt ihn so lange mit einem Schlsselstrom, der von einem Schlsselstrom-Generator erzeugt wird, bis der Eingangsdatenstrom vollstndig bearbeitet wurde. Ein Padding ist hier offensichtlich nicht notwendig.
4.4
Der Data Encryption Standard (DES)
Der Data Encryption Standard, DES, ist der Klassiker der symmetrischen Datenblock-Verschlsselungsverfahren schlechthin. Er ist ein Standard des USamerikanischen National Bureau of Standards (NBS) und ist in der Federal Information Processing Standard Publication (FIPS-Pub) 46-2 beschrieben. In diesem Dokument sind alle Details des Verfahrens beschrieben. Man kann diesen Standard benutzen, um DES zu implementieren, es ist alles vollstndig beschrieben. Der Standard wurde im Juli 1977 verabschiedet und in den Jahren 1983, 1988 und 1993 wiederholt berprft und verlngert. Er ist also bereits ber 23 Jahre alt, und es wurde noch kein Fall bekannt, in dem DES gebrochen wurde, indem eine Kryptoanalyse eingesetzt wurde, die schneller als ein Brute-Force-Angriff ist. Seine Strke, und auch die des von ihm abgeleiteten Tripple-DES-Verfahrens, liegt vor allem auch darin, dass ihm die National Security Agency (NSA) seine Qualitt nicht nur offiziell bescheinigt hat, sondern sogar selbst noch Verbesserungen vornahm. Wie kam es zu diesem, fr die NSA nun wirklich ungewhnlichen Verhalten? Die Entwicklung eines Vorlufers vom DES begann bereits Ende der 60er Jahre, in einem Forschungsprojekt von IBM unter der Leitung von Horst Feistel. Das Verfahren sollte bei Lloyds of London in den Geldautomaten, die
114
ebenfalls von IBM stammten, eingesetzt werden und erhielt den Namen Lucifer-Chiffre. IBM sah gute Mglichkeiten einer kommerziellen Vermarktung und begann mit weiteren Entwicklungen, die das Ziel hatten, das Verfahren in einem einzigen Chip bzw. einem einzigen Hybridbaustein zu implementieren. In dieser Phase wurde bereits die NSA involviert, die dem Entwickler-Team mit Rat und Tat zur Seite stand und heraus kam ein Algorithmus, dessen ursprnglicher 128-Bit-Schlssel um 72 Bit auf nur noch 56 Bit verkrzt war! Parallel dazu verffentlichte das NBS, aus dem spter das National Institute of Standards and Technology (NIST) hervorging, im Jahre 1973 eine Ausschreibung fr einen einheitlichen Verschlsselungsalgorithmus. Da die Kryptologie bis zu diesem Zeitpunkt hauptschlich im militrischen und nachrichtendienstlichen Bereich eingesetzt wurde, hielten sich die Menge und die Qualitt der eingereichten Verfahren stark in Grenzen entweder waren die Verfahren als geheim eingestuft oder unbrauchbar. Erst nach einer zweiten Ausschreibung im Jahr 1974 reichte IBM das Lucifer-Verfahren ein. Das NBS konsultierte daraufhin externe Experten, um den Algorithmus zu beurteilen, und zwar die NSA, wie Sie richtig vermutet haben. Um die genauen Vorgnge damals ranken sich Gerchte und widersprchliche Aussagen vor allem dahingehend, ob die NSA an dem Entwurf etwas verndert hatte oder nicht. Tatsache ist jedoch, dass die NSA wohl davon ausgegangen ist, dass DES nur in Chips oder nicht analysierbaren Hardwaremodulen implementiert werden wrde. Der 56-Bit-Schlssel schien fr zivile Ansprche ausreichend lang, aber fr die NSA innerhalb von Wochen oder Tagen zu brechen. Die Vernderungen am Algorithmus gegenber seinem ersten Entwurf, egal ob sie nun von IBM oder der NSA vorgenommen wurden, machten ihn sicher gegen die differenzielle Kryptoanalyse. Interessanterweise wurde die differenzielle Kryptoanalyse aber erst 1990 zum ersten Mal ffentlich beschrieben, fnfzehn Jahre nachdem DES dagegen sicher gemacht wurde. Wie dem auch sei, die NSA bescheinigte dem DES, dass er ein sicherer Algorithmus ist. Die schnellste Angriffsmethode auch heute noch ist ein BruteForce-Angriff. Das NBS verffentlichte DES dann in allen Einzelheiten, die notwendig sind, um ihn zu implementieren. Der Data Encryption Standard wurde in den letzten 23 Jahren zum wohl am weitesten verbreiteten Chiffrieralgorithmus aller Zeiten trotz aller anfnglichen Kritik. Und die war sehr laut und ist bis heute nicht verstummt. Der nur 56 Bit lange Schlssel war von Anfang an der hauptschliche Kritikpunkt. Man hatte ihn schon damals fr zu kurz gehalten und die ursprngliche Lnge von 128 Bit gefordert. Allerdings konnten sich die Kritiker damals nicht gegen die NSA durchsetzen.
115
4.4.1
Ein berblick ber DES

64-Bit-Schlsselstring 56-Bit-DES-Schlssel
64-Bit-Klartext-Block Eingangspermutation
Schlsseltransformation
K1
Runde 16 DES FeistelNetzwerk Ausgangspermuation K16
64-Bit-Chiffretext-Block
Abbildung 4.12: DES im berblick
Das Design von DES ist sehr stark hardwareorientiert. Die Entwicklungen begannen bei IBM bereits Ende der 60er Jahre, und die Rechner waren damals auf einem vllig anderen Leistungsniveau angesiedelt als heutige Systeme. Die Integrationsdichte von Bauelementen war nicht mit dem zu vergleichen, was heute mglich ist. Die Computer arbeiteten zu dieser Zeit nicht mit Mikroprozessoren, sondern mit Hybridelementen, kleinen Baugruppen auf denen logische Funktionen durch diskrete Dioden und Transistoren ausgefhrt wurden. Speichergren wurden in Byte und Kilobyte gemessen, und Massenspeicher arbeiteten mit Papier oder Magnetbndern. In diesem technischen Umfeld, und das ist wirklich bemerkenswert, wurde ein Verschlsselungsalgorithmus entwickelt, der in heutigen PCs, Workstations und Supercomputern arbeitet und in modernen Chips Durchsatzraten von ber 1.000.000.000 Bits pro Sekunde erreicht. Weil er fr den Hardwareeinsatz entwickelt wurde, ist DES nicht so leistungsfhig in Software zu implementieren. Jedoch ist dies bei der Leistungsfhigkeit heutiger Rechner kein Problem mehr und es gibt auch schon die ersten Netzwerkadapter mit integrierten Chips zur Berechnung von DES und anderen kryptographischen Verfahren.
116
DES transformiert einen 64 Bit groen Klartextblock unter Verwendung eines 56-Bit-Schlssels in einen 64 Bit groen Chiffretextblock. Der Data Encryption Standard basiert auf dem Einsatz von Feistel-Netzwerken. Er verwendet acht Feistel-Zyklen, also insgesamt 16 Runden, um dieses Ziel zu erfllen. Bevor der Klartext der ersten Runde zugefhrt wird, durchluft er eine lineare Eingangspermutation, die nach der letzten Runde durch eine Ausgangspermutation wieder aufgehoben wird. Diese beiden Permutationen haben keinen kryptographischen Ursprung, sondern sind Anfang der 70er Jahre aus Anforderungen heraus entstanden, die aus der damals verfgbaren Hardware resultierten. Die 16 Runden sind alle identisch aufgebaut, die DES-Funktion ist ebenfalls in allen Runden die gleiche. Der einzige Unterschied liegt in den 16 Teilschlsseln, die als eine der beiden Eingangsvariablen der Runden verwendet werden.
4.4.2
Die DES-Schlsseltransformation
Diese Teilschlssel werden durch Schlsseltransformationen aus dem 56-BitSchlssel erzeugt und sind jeweils 48 Bit gro. Die Schlsseltransformation ist so aufgebaut, dass nach der 16. Transformation der Originalschlssel wieder hergestellt ist.
Schlssel-String (64 Bit)
Jedes achte Bit wird entfernt
DES-Schlssel (56 Bit)

Transformation 1
28 Bit
28 Bit 28-Bit-Schieberegister
28-Bit-Schieberegister
Kompressionspermutation
Teilschlssel K1
Transformation 2
48 Bit
28 Bit
Abbildung 4.13: Die DES-Schlsseltransformation
28 Bit
117
Die Schlsseltransformation ist in Abbildung 4.13 illustriert. Der Schlssel wird als 64 Bit groer Wert an den DES-Algorithmus bergeben. Dieser entfernt jedes achte Bit daraus und benutzt die verbleibenden 56 Bits als Schlssel. Im DES-Dokument wird zwar permanent (und falsch!) von einem 64-Bit-Schlssel gesprochen, jedoch finden davon tatschlich nur 56 Bit Verwendung. Der Grund fr diesen Sachverhalt besteht darin, dass die Datenkommunikation zu Anfang der 70er Jahre nicht die Qualitt heutiger Datennetze aufwies, und jedes achte Bit in dem 64-Bit-Schlssel als Parittsbit benutzt wurde, um bertragungsfehler zu erkennen. Diese Bits sind natrlich nicht zuflliger Natur, sondern werden aufgrund der sieben Informationsbits berechnet, die links davon stehen. Der DES-Algorithmus selbst wertet die Parittsbits nicht aus, er entfernt sie einfach nur. Aus diesem Grund kann man DES auch beliebige 64-Bit-Schlssel zufhren, in denen das jeweils achte Bit kein Ergebnis einer Parittsberechnung ist, wie dies zum Beispiel auch in IPSec und IKE blich ist. In den beiden Schieberegistern (Shift), jedes enthlt eine Hlfte des 56-BitSchlssels, werden die Bits rundenabhngig um ein oder zwei Bit-Positionen nach links rotiert. Rotiert heit dabei, dass die Bits, die links hinausgeschoben werden, auf der rechten Seite des Registers wieder auf der niedrigsten Bit-Position erscheinen. Die Summe der Rotationen ist 28, so dass nach 16 Runden wieder das ursprngliche Bitmuster in den Registern steht.
4.4.3
Die DES-Funktion
In Abbildung 4.14 sehen Sie die DES-Funktion im Detail. Die Eingangswerte sind der Teilschlssel und, im Fall der ersten Runde, die rechte Hlfte des Klartextes oder im Weiteren die rechte Hlfte des Ausgangsblocks der vorangegangenen Runde (Rn). Der Wert Rn wird in einer Expansionspermutation auf 48 Bit erweitert und mit den 48 Bit des entsprechenden Teilschlssels Exklusiv-Oder-verknpft. Das Ergebnis wird in einer nichtlinearen S-BoxSubstitution wieder auf 32 Bit reduziert und durchluft anschlieend eine lineare Permutation. Das Resultat ist das Ergebnis der DES-Funktion. Dieses Ergebnis wird im Feistel-Netzwerk mit der linken Hlfte des Klartextes oder der Ausgabe der vorangegangenen Runde Exklusiv-Oder-verknpft.! Die S-Boxen der DES-Funktion sind der wichtigste und kritischste Teil des Data Encryption Standard. Ihre Funktion entscheidet ber Sicherheit oder Unsicherheit des Verfahrens. Wie die Funktionswerte, in Abbildung 4.15 sehen Sie die fnfte S-Box, erzeugt wurden, ist nicht offen gelegt! Ob die Entwickler einfach nur gewrfelt haben oder wochenlange Berechnungen vorausgegangen sind, bleibt nach wie vor im Dunkeln. Auch heute, 23 Jahre nach der offiziellen Verabschiedung des Standards, wahren noch alle Beteiligten ihr Stillschweigen. Es ist jedoch so, dass eine mglichst gleichmige, mehrfache Substitution aller Bits erreicht wurde. Lediglich inoffiziell wurde bekannt,
118
Ri-1
32 Bit
48 Bit 48 Bit 48 Bit
Teilschlssel Ki
Nichtlineare S-Box-Substitution
32 Bit
Permutation (P-Box) 32 Bit

Ergebnis der DES-Funktion
Abbildung 4.14: Die DES-Funktion
dass die Werte in den S-Boxen, die angeblich von der NSA gegenber dem originalen IBM-Entwurf gendert wurden, einen zuverlssigen Schutz gegen die differenzielle Kryptoanlayse bieten. Dies ist richtig, zeigt aber auch, dass dieses Verfahren, und vor allem auch der Schutz davor, der NSA schon vor 25 Jahren bekannt gewesen ist!
Eingabe-Register (48 Bit)
S-Box -1S-Box -2S-Box -3S-Box -4S-Box -5S-Box -6S-Box -7S-Box -8-
Ausgabe-Register (32 Bit)

Bits 1 und 6 adressieren eine Zeile Bits 2 bis 5 adressieren eine Spalte Beisp.: Subst(101010) = 1101 (13)
S-Box - 5 0 0 1 2 3 1 2 3 4 5 6 7
9 10 11 12 13 14 15 0 14 9 9 8 6 3 0 14 4 5 3
2 12 4 1 7 10 11 6 14 11 2 12 4 7 13 1 4 2 1 11 10 13 7 8 11 8 12 7 1 14 2 13
8 5 3 15 13 5 0 15 10 3 5 9 12 5 6 6 15 0 9 10
Abbildung 4.15: Die fnfte S-Box der DES-Funktion
119
4.4.4
Die DES-Entschlsselung
Durch eine DES-Entschlsselung wird ein 64 Bit groer Chiffretext mit Hilfe des 56-Bit-Schlssels, mit dem dieser Chiffretext erzeugt wurde, wieder in einen 64 Bit groen Klartextblock transformiert. Dies geschieht mit dem gleichen Algorithmus. Denn Sie haben im Abschnitt ber Feistel-Netzwerke gelesen, dass man dieses sowohl zum Ver- als auch zum Entschlsseln benutzen kann. Im Fall von DES laufen die Runden dazu einfach nur in umgekehrter Reihenfolge ab. Dies ist einfach dadurch zu realisieren, dass der Prozess in der ersten Runde mit dem Teilschlssel 16 beginnt und in der letzten Runde mit dem Teilschlssel 1 endet. Praktisch implementieren kann man dies ganz einfach, indem man die Richtung in den Schieberegistern umkehrt. Somit kann man den Algorithmus sowohl zum Verschlsseln als auch zum Entschlsseln benutzen. Genau genommen ist die Entschlsselung eine Verschlsselung, denn wenn man statt des Chiffretextes einen Klartext in die Dechiffrierung einspeisen wrde, wrde man einen Chiffretext erhalten. Dies macht man sich auch beim Triple-DES-Verfahren zunutze, um zum DES-Algorithmus kompatibel zu sein.
4.5
Triple-DES
Was fr ein Eigentor die NSA sich mit DES geschossen hatte, wurde eigentlich erst mit der Entwicklung und Einfhrung von Triple-DES deutlich. Denn dieses Verfahren, um es gleich vorweg zu nehmen, kann auch eine National Security Agency nicht knacken. DES ist fr die NSA kein Problem, da kommt ein Brute-Force-Angriff in Sekundenschnelle zu einem Ergebnis oder besser gesagt zu einem Schlssel mit Triple-DES ist allein schon der Versuch reine Zeitverschwendung. DES war schon zu Zeiten seiner Einfhrung 1977 zur Zielscheibe scharfer Kritik einer ganzen Reihe von Kryptologen geworden, unter ihnen auch Persnlichkeiten wie Whitfield Diffie. Deren Kritik richtete sich dabei weniger gegen den Algorithmus selbst als gegen dessen wirksame Schlssellnge von nur 56 Bit. Diese wurde damals schon als viel zu kurz fr ernsthafte Anwendungen angesehen. Diese Kritik hat die NSA aber herzlich wenig interessiert, denn wenn jemand die technischen Ressourcen hatte, DES mit einem Brute-ForceAngriff zu entschlsseln, dann diese Organisation. Die Zeit arbeitete fr die NSA, denn die Rechner wurden immer leistungsfhiger, und damit wurde die Zeit, die zur Berechnung eines DES-Schlssels bentigt wurde, immer krzer, whrend sich an der Sicherheit des Algorithmus wegen seiner festen Schlssellnge nichts nderte. Denn schnellere Rechner verschlsseln zwar schneller, aber dadurch nicht sicherer. Auerdem hatte die NSA ja auch noch Plan B in der Schublade, die US-Exportbeschrnkungen fr kryptographische Produkte. Die National Security Agency hat die Macht, andere Ministerien,
120
Triple-DES
wie zum Beispiel das US-Auenhandelsministerium, zu ihrem verlngerten Arm zu machen und die Ausfuhr bestimmter Produkte ganz einfach zu verbieten oder wenigstens per Genehmigungsverfahren regulieren zu lassen. Aber mit zunehmender Entwicklung der Datenverarbeitung wurde der DESSchlssel immer mehr zum Schwachpunkt des ganzen Verfahrens. Denn mittlerweile konnten kleine Organisationen oder sogar gut ausgerstete Einzelpersonen den Schlssel mit einem Brute-Force-Angriff brechen. Sie haben in diesem Kapitel erfahren, dass der Schutz gegen einen Brute-Force-Angriff genau genommen recht einfach ist, man braucht nur den Schlssel lnger zu machen. Denn mit jedem Bit mehr Schlssellnge verdoppelt sich auch die Suchzeit. Allerdings bedingt dies einen Algorithmus mit variabler Schlssellnge, und genau das ist DES nicht. Der DES-Schlssel ist 56 Bit lang, und die Erzeugung der Teilschlssel aus jedem einzelnen dieser Bits ist im Standard genau festgelegt.
Chiffretext (64 Bit)
Klartext (64 Bit)
DES Encrypt 56 Bit
DES Decrypt 56 Bit
DES Encrypt
56 Bit
Schlssel K1
Schlssel K2
Schlssel K3
Abbildung 4.16: Triple-DES verkettet drei DES-Durchlufe zu einer Verschlsselung.
Aus dieser Sackgasse schien es auf den ersten Blick keinen praktikablen Ausweg zu geben. Denn den Algorithmus zu ndern, htte eine Inkompatibilitt zu bestehenden Systemen bedeutet. Das gleiche galt fr die Entwicklung eines gnzlich neuen Algorithmus. Der Ausweg, der sich bot, hie Triple-DES, also eine dreifache Verschlsselung mit DES, und damit die Mglichkeit, auch Standard-DES benutzen zu knnen. Triple-DES verkettet, wie in Abbildung 4.16 zu sehen ist, drei DES-Durchlufe miteinander, die jeweils unterschiedliche Teilschlssel benutzen. Es erfolgt zuerst eine Verschlsselung mit dem Schlssel K1, dann eine Entschlsselung mit dem Schlssel K2 und zuletzt wieder eine Verschlsselung mit dem Schlssel K3. Somit wurde der Klartext dreifach verschlsselt, und fr einen Brute-Force-Angriff msste man alle 2168 Mglichkeiten ausprobieren, die die drei Schlssel zusammen bieten. Und dies ist nicht mglich. Die geforderte Kompatibilitt zu DES erreicht man ganz einfach dadurch, dass man den 56-Bit-DES-Schlssel gleichzeitig allen drei Stufen von Triple-DES zufhrt.
121
An dieser Stelle ist noch eine Sonderversion zu erwhnen, die gelegentlich zu finden ist und nur eine effektive Schlssellnge von 112 Bit aufweist. In dieser Variante sind der erste und der letzte Schlssel der drei Triple-DES-Stufen gleich. Somit ergibt sich fr einen Brute-Force-Angriff ein zu durchsuchender Schlsselraum von 112 Bit. Fr diesen Wert ergeben sich allerdings Suchzeiten, die in Jahrtausenden gemessen werden, so dass auch hier noch von einem starken Algorithmus gesprochen werden kann.
4.6
Cipher Block Chaining (CBC)
Bei aller Strke von DES, abgesehen von seiner Grund-Schlssellnge, und Triple-DES es sind monoalphabetische Algorithmen! Das heit, dass zu einem gegebenen Schlssel gleiche Klartextblcke auch gleiche Chiffretextblcke erzeugen. Damit wre aber die Mglichkeit eines Angriffs mit statistischen Methoden gegeben, da ein Angreifer in der Praxis sehr schnell erkennen kann, wenn sich bestimmte Muster im Chiffretext wiederholen. Zum Beispiel erzeugen die immer gleichen Signaturen in E-Mails oder auch die Mail-Header in der Regel mehrere Blcke Chiffretext, die sich untereinander auch gleichen. Ein solcher Angriff vermag jedoch nicht den Schlssel zu berechnen. Es ist aber mglich, auf den Klartext zurckzuschlieen, was auch schon schlimm genug ist. Aus diesem Grunde wird DES, wie auch alle anderen Blockchiffre-Verfahren, in einer speziellen Betriebsart, dem CBC-Modus (Cipher Block Chaining) betrieben. Das Ziel dieses Verfahrens ist es, mit Hilfe eines monoalphabetischen Block-Chiffreverfahrens eine polyalphabetische Ver- oder Entschlsselung durchzufhren. Es sollen also gleiche Klartextblcke zu einem gegebenen Schlssel verschiedene Chiffretextblcke erzeugen.
Klartextblock MI LetzterChif fretextblock C I-1
DES Encrypt
CI
Chiffretextblock
Abbildung 4.17: Das Cipher Block Chaining eliminiert den Monoalphabetismus von DES.
122
Cipher Block Chaining (CBC)
CBC erreicht dies, indem jeder Klartextblock vor der Verschlsselung mit dem unmittelbar vorher erzeugten Chiffretextblock Exklusiv-Oder-verknpft wird. Auf diese Weise ist garantiert, dass sich die Blcke, die dem DES-Algorithmus als Eingangswert zugefhrt werden, von den ursprnglichen Eingangsblcken unterscheiden. Demzufolge erzeugen gleiche Klartextblcke verschiedene Chiffretextblcke, und es liegt praktisch eine polyalphabetische Verschlsselung vor.
4.6.1
Die Funktionsweise von CBC
Wie in Abbildung 4.17 zu sehen ist, benutzt man zur Exklusiv-Oder-Verknpfung den Chiffretext des unmittelbar vorher verschlsselten Blocks. Was aber macht man mit dem ersten Klartextblock? Um dieses Problem zu lsen, bentigt man noch einen weiteren Parameter, den so genannten Initialisierungsvektor (IV). Dieser Initialisierungsvektor, dessen Lnge gleich der Lnge der Klartextblcke sein muss, also 64 Bit im Falle von DES, ist hinsichtlich seiner Erzeugung und Vertraulichkeit recht unkritisch. In der Praxis erzeugt man einfache Pseudo-Zufallszahlen oder benutzt den gespeicherten Chiffretext der letzten Verschlsselung. In Abbildung 4.18 sehen Sie, dass der Initialisierungsvektor sowohl zum Ver- als auch zum Entschlsseln benutzt wird. Im Gegensatz zum Schlssel und dem Klartext braucht der IV aber nicht geheim zu sein. Manche Protokolle wie IP Security bertragen ihn in jedem Datenpaket unverschlsselt vor dem Chiffretext.
M M M
IV
E E E
D
IV
E=Encrypt, D=Decrypt, M=Klartext, C=Chiffretext, IV=Intialisierungsvektor
Abbildung 4.18: CBC-Ver- und -Entschlsselung mit explizitem Initialisierungsvektor
123
Wichtig fr den Initialisierungsvektor ist, dass er sich whrend der Verwendungsdauer des Schlssels nicht wiederholt, dass also bei verschiedenen Paketen oder bertragungssitzungen nicht der gleiche verwendet wird.
4.7
Ausblick: Der Advanced Encryption Standard
Obwohl er immer noch nicht geknackt ist und man mit Triple-DES das Problem des kurzen, nur 56 Bit langen Schlssels entschrft hat, sucht man seit einiger Zeit schon nach einem Nachfolger fr den doch schon etwas betagten DES-Standard. Man, das ist das amerikanische National Institute of Standards and Technology (NIST), eine Behrde des US-Handelsministeriums, die sich unter anderem mit Standards fr IT-Sicherheit befasst. Am 2. Januar 1997 begann das NIST mit den Vorbereitungen fr die Ausschreibung des Advanced Encryption Standard (AES), der zur Sicherung von Informationen in US-Regierungsbehrden bis weit in das nchste Jahrhundert geeignet sein sollte. Da dieser nationale Behrdenstandard auch von der USamerikanisch dominierten Internet Engineering Task Force (IETF) als zwingend vorgeschriebener Verschlsselungsalgorithmus in den IPSec-Standard adaptiert werden wird, sind hier ein paar Worte zum Auswahlverfahren und dem zum Zeitpunkt der Drucklegung dieses Buches verbliebenen, vorgeschlagenen und vorlufigen AES-Kandidaten angebracht. Am 12. September 1997 wurden Industrie und Forschung in aller Welt um Einreichung eines passenden Algorithmus gebeten. Dies sollte ein nicht als geheim eingestuftes, offen gelegtes und weltweit kostenfreies Verfahren sein, das bestimmten Anforderungen gengen musste: Der AES muss ffentlich spezifiziert werden und darf daher nicht als geheim eingestuft sein. Der AES muss ein symmetrischer 128-Bit-Blockchiffrieralgorithmus sein. Der AES muss eine, bei 128 Bit beginnende, nach oben erweiterbare Schlssellnge untersttzen. Explizit untersttzt werden mssen Schlssel mit 128, 196 und 256 Bit. Der AES muss sowohl in Software als auch in Hardware zu implementieren sein. Der AES muss entweder frei verfgbar sein oder unter die ANSI-Patentpolitik fallen.
124
Die eingereichten Algorithmen werden, sofern sie diesen Bedingungen gengen, intensiv auf folgende Punkte hin geprft: Sicherheit Performance und Effizienz Speicheranforderungen, insbesondere Arbeitsspeicherverbrauch Eignung zur Hardware- und Software-Implementierung Eignung zum Einsatz auf Chipkarten Einfachheit Flexibilitt Lizenzbedingungen Im Hinblick auf zuknftige Entwicklungen, insbesondere im Bereich Electronic Commerce, mssen die Algorithmen sowohl sehr performant in Software als auch in Hardware implementiert werden knnen. Auch an Smartcards wurde gedacht, die Algorithmen sollen auf den verschiedenen Modellen mit dem Smartcard-blichen geringen Arbeitsspeicher von teilweise nur 64 Byte auskommen! Am 20. August 1998 verffentlichte das NIST die Beschreibungen von fnfzehn Algorithmen, die von den unterschiedlichsten Organisationen aus zwlf verschiedenen Lndern zur Prfung eingereicht wurden. Es wurde anschlieend weltweit um Kommentare zu den AES-Kandidaten gebeten, um ebenfalls mit mglichst breiter Mitwirkung die Sicherheit, Performance und universelle Einsetzbarkeit der Verfahren kritisch zu beurteilen. Dieses Verfahren wurde am 15. April 1999 abgeschlossen. Aufgrund dieser Kommentare und ihrer weiteren Auswertung blieben letztendlich fnf, nach Ermessen des NIST ernst zu nehmende Algorithmen brig. Dies waren MARS, RC6, Rijndael, Serpent und Twofish. Der Prozess soll im Sommer 2001 abgeschlossen sein, wobei sich das NIST auch ausdrcklich offen hlt, dass der AES auch aus mehreren Algorithmen bestehen kann. Inzwischen, Stand Dezember 2000, hat sich das NIST fr einen der Kandidaten entschieden und diesen als vorlufigen AES vorgeschlagen. Ein weiterer Algorithmus wurde bisher nicht ausgewhlt, da das NIST TripleDES als geeigneten Backup-Algorithmus ansieht. Die offizielle Verabschiedung des Standards wird fr 2001 erwartet falls sich bis dahin keine neue politische Situation in den USA ergibt und die NSA dagegen einschreitet.
125
4.7.1
AES-Software-Implementierung
Da der alte DES-Standard, die Entwicklungen bei IBM begannen bereits Ende der 60er Jahre, fr die damals verfgbare Hardware entwickelt wurde, sind dessen Software-Implementierungen nicht besonders leistungsfhig. Es mssen sogar, will man den DES standardkonform in Software implementieren, kryptographisch vllig sinnlose, sich gegenseitig aufhebende Operationen wie die lineare Eingangs- und Ausgangspermutation implementiert werden, nur weil sie Anfang der 70er Jahre wegen der damals zur Verfgung stehenden Hardware ntig waren. AES hingegen soll mglichst unabhngig von der eingesetzten Systemarchitektur sein. Sowohl heutige Intel-, PowerPC- oder Sparc-Prozessoren als auch zuknftige Prozessoren mssen untersttzt werden knnen. Deshalb ist das Design auch auf hhere Programmiersprachen hin abgestimmt. Gewisse Registerbreiten oder spezielle Prozessorbefehlsstze drfen nicht erforderlich sein, eine Implementierung in C luft sowohl auf einem Z80- als auch auf einem PowerPC-Prozessor. So fordert das NIST, dass sowohl eine ANSI-C-Referenzimplementierung im Sourcecode als auch optimierte Implementierungen in ANSI-C und Java zum eingereichten Algorithmus mitgeliefert werden. Eine Organisation, die einen Algorithmus einreicht, muss weiterhin garantieren, dass er zum einen auf 8-Bit-Prozessoren in Smartcard-Umgebungen zu implementieren ist und zum anderen auch als Basis fr Stromchiffrierverfahren, Pseudo-Zufallsgeneratoren, MAC-Generatoren und Hashverfahren verwendet werden kann. Somit wurden durch das Einreichen der Algorithmen eine Reihe von Sourcen in C, Java und Assembler verffentlicht, teilweise schon mit Optimierungen fr bestimmte Prozessoren oder Smartcards. Da alles wirklich sehr gut dokumentiert und beschrieben ist, ist dieser ffentliche Auswahlprozess eine wahre Fundgrube fr kryptographisch Interessierte.
4.7.2
AES-Hardware-Implementierung
Bei einer Verschlsselung mit sehr hoher Bandbreite setzt man nicht selten Hardwarelsungen ein, sowohl als Beschleunigerkarten, um das Muttersystem zu entlasten, als auch als reine Verschlsselungsgerte. Man kann es schon fast als Faustregel nehmen, dass symmetrische Blockchiffrierverfahren als echte Hardware-Implementierung um den Faktor 10 schneller sind als ihr Softwarepedant. Das kann sich zwar von Algorithmus zu Algorithmus unterscheiden, und bestimmte Verfahren sind auch in Software sehr gut zu optimieren, jedoch oft auf Kosten eines immensen Speicherverbrauchs. Oder man programmiert in Maschinensprache und benutzt bestimmte Prozessor-Eigenschaften dann allerdings auf Kosten der Portabilitt.
126
Bei der Hardware-Implementierung gibt es drei verschiedene Mglichkeiten: Der Algorithmus wird in einem speziell fr ihn entwickelten Chip implementiert. Der Algorithmus wird in speziellen Prozessoren, wie digitalen Signalprozessoren (DSP), Encryption-Chipstzen und hnlichem per Mikrocode implementiert. Der Algorithmus wird in einer Smartcard implementiert. Die Geschwindigkeiten hierbei unterscheiden sich teilweise erheblich. Am besten schneidet meist der Chip ab, der speziell fr den Algorithmus entworfen wurde. Hiermit sind nicht programmierbare Microcontroller gemeint, sondern wirklich neue Maskendesigns. An zweiter Stelle hinsichtlich der Geschwindigkeit sind Implementierungen in DSPs und hnlichen Chips zu finden. Implementierungen in Smartcards fallen genau genommen gar nicht unter die Rubrik Hardware-Implementierung. Da sie aber sehr oft flschlicherweise in diesem Zusammenhang genannt werden, sind sie hier mit aufgefhrt. Denn bei einer Smartcard entsteht genau der umgekehrte Effekt: Das Ganze wird nicht schneller, sondern langsamer, und zwar meist um Grenordnungen. Dies wird auch verstndlich, wenn wir uns einmal das Innenleben einer Smartcard anschauen. Es handelt sich dabei einfach um eine kleine, flache Computerzentraleinheit mit CPU, ROM, RAM und einfacher I/O-Peripherie. Die Auslser der Performanceprobleme von Smartcards sind zum einen der Prozessor, meist ein 8-Bit-System auf Z80- oder 6805-Basis mit Geschwindigkeiten unter 20 MHz, und zum anderen der sprliche Arbeitsspeicher von oft nur 64 oder 128 Byte Gre! Diese beiden Faktoren zusammen verhindern eine wirkungsvolle Optimierung, und es tritt auch noch ein weiterer negativer Effekt auf: Der Schlssel und je nach Algorithmus viele Werte wie S-Box-Eintrge mssen laufend dynamisch neu berechnet und wieder gelscht werden, da die Daten aufgrund der geringen Speicherkapazitt nicht dauerhaft im Arbeitsspeicher bleiben knnen. So knnen Smartcards leicht hundertmal langsamer als Implementierungen auf einem 200-MHzPentium-Pro-PC sein; als aktuellen Wert fr ihre Implementierung nennt die Twofish-Truppe um Bruce Schneier zum Beispiel den Faktor 92.
4.7.3
AES-Geschwindigkeit und Optimierungsmglichkeiten
Die Geschwindigkeiten der AES-Kandidaten sind schon als Software-Implementierung sehr hoch. Somit ist ihre Sicherheit bei Schlssellngen bis zu 256 Bit und mehr schon signifikant hher als die von Triple-DES und das bei einer Geschwindigkeit, die deutlich ber der von 56-Bit-DES liegt.
127
MARS von IBM soll auf einem Pentium-Pro mit 200 MHz einen Durchsatz von 65 Mbit/s bringen, die Geschwindigkeit von RC6 wird von der Ron-RivestTruppe auf einem 180-MHz-Pentium-Pro-PC mit 64 MB RAM und NT4.0, also unter realen PC-Bedingungen, mit 42 Mbit/s bei beliebiger Schlssellnge angegeben. Wer schon Erfahrung in der Programmierung hat, wei, dass sich zwei Optimierungsmglichkeiten oft gegenseitig ausschlieen: die Optimierung auf Geschwindigkeit und die auf Arbeitsspeicherverbrauch. Mit anderen Worten: Mit ausreichend Speicher kann man ein Programm sehr schnell machen, und umgekehrt fhrt das Optimieren auf keinen Speicher meist zum Verlangsamen der Ausfhrungsgeschwindigkeit. Aus diesen Grnden finden sich meist zwei Varianten, in denen die AES-Kandidaten implementiert werden. Zum einen gibt es die Variante, bei der aufgrund von Hardwarelimitierungen sehr wenig Speicher zur Verfgung steht und bei der man auf Speicherplatz optimiert. Zum anderen gibt es die Variante, bei der gengend Speicher vorhanden ist, um die Ausfhrungsgeschwindigkeit zu optimieren. Was bei Algorithmen, die Funktionen wie schlsselabhngige S-Boxen einsetzen, noch hinzukommen kann, ist die Mglichkeit, eine groe Anzahl von Zwischenwerten vorauszuberechnen und zu speichern. Damit hat man zwar zu Beginn der Verschlsselung eine gewisse Verzgerung, kommt dafr aber bei allen nachfolgenden Blcken in den Genuss einer noch hheren Geschwindigkeit.
4.7.4
And the winner is . Rijndael
Zum Erstaunen vieler Beobachter fiel die Vorentscheidung des NIST auf einen Algorithmus, der nicht in den USA entwickelt wurde. Der Rijndael-Algorithmus wurde in Europa, genauer gesagt in Belgien, entwickelt. Er ist eine Entwicklung von Dr. Joan Daemen von Proton World International und von Dr. Vincent Rijmen von der katholischen Universitt Leuven. Aus deren Nachnamen wurde der Name des Algorithmus abgeleitet. Rijndael hat sich letztendlich gegen die Entwrfe von IBM, RSA, Counterpane und anderer hochkartiger Kryptographie-Spezialisten durchgesetzt. Der Algorithmus wurde vom NIST ausgewhlt, weil er die ausgewogenste Verteilung hinsichtlich aller gestellten Anforderungen aufwies und gleichermaen leistungsfhig sowohl in Soft- und Hardware als auch auf Hochleistungs-Parallelrechnern und Smartcards zu implementieren ist. Die Sicherheit des Verfahrens entspricht ebenfalls den gestellten Anforderungen. Darber hinaus ist der Rijndael-Algorithmus eines der ganz wenigen symmetrischen Verschlsselungsverfahren, das nicht auf Feistel-Netzwerken beruht. Es wird zwar auch eine Reihe von Transformationsrunden durchlaufen, aber in jeder dieser Runden werden alle Bits transformiert und nicht nur die Hlfte der Bits wie im Feistel-Netzwerk. Rijndael ist ein sehr schneller Algorithmus,
128
Asymmetrische Verschlsselungsverfahren
der auch auf Smartcards sehr performant zu implementieren ist. Sein Bedarf an Hardware-Ressourcen ist dabei ebenfalls sehr gering. Rijndael kann auch sehr gut auf Parallelrechnern implementiert werden, da sich seine Transformationen fr die Verschlsselung eines einzigen Blocks sehr gut parallelisieren lassen. Die nichtlineare Komponente von Rijndael bilden, wie in allen anderen Algorithmen auch, S-Boxen auf Byte-Basis, die hier aber auf dem endlichen GaloisFeld GF(28) beruhen. Die Anzahl der zu durchlaufenden Runden hngt auch von der Lnge des Schlssels ab, und somit sinkt bei Rijndael der Durchsatz bei groen Schlsseln! Jedoch kann der Algorithmus sehr schnell die Werte der S-Boxen vorberechnen und, falls die Systemumgebung dies zulsst, auch speichern, um die eigentliche Transformation zu beschleunigen. Wer sich die Beschreibung des Algorithmus ansieht und kein Zahlentheoretiker ist, der wird bei einem Vergleich mit der Einfachheit von DES zuerst einmal erschrecken. Allerdings ist die Abhngigkeit der S-Boxen von bestimmten mathematischen Strukturen auch ein Kritikpunkt, denn hier knnte sich theoretisch ein wunder Punkt herauskristallisieren, falls sich quivalente mathematische Beschreibungen zu Rijndael entwickeln lieen. An dieser Stelle vielleicht noch ein Hinweis zu den anderen fnf Finalisten: Das NIST betont ausdrcklich, dass sich, insbesondere im Hinblick auf die Sicherheit der Algorithmen, nicht herausgestellt habe, dass die Verlierer schlechter oder unsicherer seinen als Rijndael. Sie werden in Zukunft mit Sicherheit auf den einen oder anderen Algorithmus stoen, da die Unternehmen ihre Entwicklungen sicher vermarkten werden. Diese Verfahren sind sicher und in entsprechenden Umgebungen schnell in jedem Fall aber schneller als DES und mindestens genauso sicher!
4.8
In diesem Kapitel wurde bisher stillschweigend davon ausgegangen, dass die symmetrischen Schlssel zum Chiffrieren und Dechiffrieren bei Sender und Empfnger bekannt sind. Wie sie dorthin gelangt sind, wurde nicht weiter beachtet. Dies kann jedoch ein sehr schwerwiegendes Problem sein, insbesondere dann, wenn sehr viele mgliche Sender und Empfnger existieren oder sich zwei Partner vorher gar nicht kennen. Wo liegt das Problem?
4.8.1
Die kurze Geschichte der Public-Key-Kryptographie
Nehmen wir einmal den Fall an, dass zwei Personen ihre Kommunikation, bespielsweise ihre Internet-E-Mail, verschlsseln mchten. Da beide sehr sicherheitsbewusst sind, mchten sie das Triple-DES-Verfahren benutzen. In
129
diesem Fall knnen sich beide persnlich treffen und den Schlssel austauschen, oder sie knnen ihn sich per Post auf Papier oder Datentrger zustellen. Aber in keinem Fall knnen sie den Austausch aber ber das Internet vornehmen, denn dann knnte ein Unbefugter mitlesen! Selbst das Postverfahren ist nicht hundertprozentig sicher. Wenn beide zudem einige tausend Kilometer voneinander entfernt wohnen, ist ein persnliches Treffen unvorteilhaft, insbesondere dann, wenn es sich nicht nur um zwei Personen, sondern um die 100.000 Mitarbeiter eines Unternehmens handelt. Und was ist, wenn sich beide gar nicht vorher persnlich kennen? Oder wenn Sie, um ein praktisches Beispiel zu nehmen, sich an einem E-Commerce-Webserver anmelden und Ihre Kreditkarteninformationen verschlsselt bertragen mchten? Wie einigen Sie und der Server sich auf einen symmetrischen Schlssel? Dieses Problem war fr die Kryptologen in aller Welt eine harte Nuss. Den meisten erschien das Problem praktisch unlsbar, so dass sich in den sechziger und siebziger Jahren fast niemand mehr ernsthaft mit der Thematik der Schlsselverteilung auseinander setzte. Zum Glck gab es aber noch einige Unentwegte, die sich den Kopf darber zerbrachen, wie dieses Problem gelst werden konnte. Zwei dieser Forscher, die Mathematiker Whitfield Diffie und Martin Hellman, begannen im Jahr 1974 eine Zusammenarbeit, deren Resultat (sowie die daraus folgenden Entwicklungen) die Kryptologie revolutionieren sollte. Ralph Merkle, eine weitere Kryptographie-Gre, stie noch zu dem Team, und zwei Jahre spter, im Jahr 1976, war es soweit. Martin Hellman hatte einen Ansatz gefunden, der auf dem Problem des diskreten Logarithmus (siehe unten) beruhte und als Diffie-Hellman-Merkle-Verfahren Geschichte machte. Bei der Vorstellung ihrer Lsung vor einem verblfften Fachpublikum anlsslich einer Tagung der National Computer Conference 1976 staunten die Experten ber die geniale Einfachheit und gleichzeitige Strke des Verfahrens, und den ersten Teilnehmern dmmerte die wirkliche Bedeutung dessen, was sie gerade eben gehrt hatten, fr die weitere Entwicklung unserer Informationsgesellschaft. Fr Whitfield Diffie war das aber genau genommen nur ein halber Durchbruch. Das Verfahren eignete sich zwar hervorragend zum Schlsseltausch, aber man konnte keine Daten damit verschlsseln. Ihm schwebte die ganze Zeit ber ein gnzlich neues Prinzip vor, bei dem man etwas mit einem speziellen Schlssel verschlsseln konnte, das nur mit einem dazugehrigen anderen Schlssel wieder zu entschlsseln war ein asymmetrisches Verschlsselungsverfahren. Der Schlssel zum Verschlsseln konnte bei diesem Konzept jedermann weltweit bekannt sein, denn er konnte ja nur zum Ver-, aber nicht mehr zum Entschlsseln benutzt werden. Als Methode zur Realisierung schwebte Diffie eine besondere Einwegfunktion vor, zu der es eine so genannte Hintertr- oder Falltr-Funktion (trapdoor function) gibt, die deren Einwegfunktionalitt umgehen kann. Die Kenntnis dieser Hintertr ist die Basis fr die Entschlsselungsfunktion.
130
Whitfield Diffie stellte dieses Konzept 1975 der ffentlichkeit vor, und tatschlich begannen einige Forscher, allen voran natrlich Diffie, Hellman und Merkle, damit, die geeigneten Einwegfunktionen zu suchen jedoch vorerst ohne Erfolg. Die Idee war super, nur eine passende Einwegfunktion nebst dazugehriger Hintertr-Funktion war einfach nicht zu finden. Erst im April 1977 und ber 3.000 Meilen von der Wirkungssttte Whitfield Diffies entfernt, an der Ostkste der USA, im Labor fr Computerwissenschaften des Massachusetts Institute of Technology (MIT), fand ein anderes Forscher-Trio eine Lsung des Problems. Dr. Ronald Rivest hatte dort ein Jahr zuvor den Artikel von Diffie und Hellman ber die asymmetrische Kryptographie gelesen und unmittelbar begriffen, was fr ein Potenzial darin verborgen lag. Er konnte damals auch seine beiden Kollegen Adi Shamir und Leonard Adleman berzeugen, sich mit ihm zusammen auf die Suche der Einwegfunktion und ihrer Hintertr zu machen. Nachdem sie ein Jahr lang zunehmend frustrierter eine ganze Reihe unbrauchbarer Anstze aussortiert hatten, kam Ron Rivest im April 1977 ein Verfahren in den Sinn, das heute als das RSA-Verfahren (siehe unten), benannt nach den Initialen der drei Forscher, weltbekannt und eines der am meisten eingesetzten so genannten Public-Key-Verfahren ist. RSA machte sich ein anderes mathematisches Problem zunutze als das DiffieHellman-Verfahren, nmlich das so genannte Faktorisierungsproblem. Es ist nmlich sehr einfach und schnell mglich, zwei sehr groe Primzahlen miteinander zu multiplizieren, aber es ist praktisch unmglich, das Ergebnis wieder in die ursprnglichen Faktoren zu zerlegen. Die zur Entschlsselung notwendige Hintertr des Verfahrens leitet sich aus der Kenntnis der beiden Primfaktoren ab. Beide Verfahren, RSA- und Diffie-Hellman, wurden in den USA kurz nach ihrer Verffentlichung patentiert. Jawohl, Sie haben richtig gelesen, patentiert, denn obwohl es in den USA, wie auch in praktisch allen anderen Staaten, normalerweise nicht mglich ist, mathematische Algorithmen zu patentieren, wurden beide Verfahren geschtzt. Jedoch sind beide Patente mittlerweile abgelaufen, und jedermann kann die Verfahren frei von irgendwelchen Gebhren einsetzen.
4.8.2
Das Grundprinzip der Public-Key-Kryptographie
Die Grundpfeiler der Public-Key-Kryptographie sind ungelste oder so genannte schwierige mathematische Probleme. Besonders geeignet sind mathematische Funktionen, die sich in eine Richtung sehr einfach und schnell berechnen lassen, deren Umkehrung hingegen sehr schwierig und langwierig ist. Langwierig bedeutet hier Zeitspannen zwischen einigen tausend Jahren und dem Alter des Universums. Praktisch gesehen sind solche Einwegfunk-
131
tionen also nicht umkehrbar. Nicht umkehrbar bedeutet aber auch, dass man etwas, was durch diese Funktionen verschlsselt wurde, nicht mehr in sinnvoller Zeit entschlsseln kann. Das ist richtig und bei speziellen Algorithmen, wie dem Diffie-Hellman-Verfahren zur Schlsselerzeugung, auch essenziell. Andere Public-Key-Algorithmen, die sowohl verals auch entschlsseln sollen, bedienen sich eines speziellen Tricks, der so genannten Falltr-Funktion (trapdoor function). Diese Funktion kennt eine Art und Weise, wie sie mit einem speziellen Geheimnis, dem privaten Schlssel, den Chiffretext wieder in den Klartext transformieren kann. Wie dieser Trick funktioniert, werden Sie nach dem folgenden kleinen berblick ber die mathematischen Grundlagen der Public-Key-Kryptographie am Beispiel des RSA-Verfahrens erfahren.
4.8.3
Mathematische Grundlagen
Dieser Abschnitt soll nur einen recht oberflchlichen, aber zum Verstndnis notwendigen berblick ber die Mathematik geben, die in der Public-KeyKryptographie benutzt wird. Wer sich tiefer in das Gebiet der Zahlentheorie einarbeiten mchte, dem sei die weiterfhrende Literatur hierzu empfohlen. Primzahlen Eine Primzahl ist eine Zahl, die nur durch 1 und sich selbst teilbar ist. Es gibt unendlich viele Primzahlen. Die einzig bekannte gerade Primzahl ist die 2, alle anderen sind ungerade. Jede gerade Zahl grer als 2 ist die Summe zweier Primzahlen. Das ist zwar mathematisch nicht bewiesen, sondern nur eine Vermutung, die so genannte Goldbachsche Vermutung, trifft aber auf alle bisher untersuchten geraden Zahlen zu. Die Hufigkeit des Vorkommens von Primzahlen nimmt mit wachsender Gre der Zahlen ab. Im Bereich von Zahlen bis 512 Bit Lnge gibt es ca. 10151 Primzahlen. Im Vergleich dazu besteht unser Universum aus nur ca. 1077 Atomen! Das vereinfacht die Erzeugung von Primzahlen auf Zufallsbasis enorm, denn die Wahrscheinlichkeit, dass zwei unabhngige Systeme zufllig die gleiche Primzahl auswhlen, ist kleiner als die Wahrscheinlichkeit, sein Leben lang jeden Tag im Lotto zu gewinnen. Aber wie erzeugt man auf Zufallsbasis eine groe Primzahl? Natrlich sind nicht alle Primzahlen bekannt, und man kann auch vor allem nicht alle 10151 Primzahlen im Bereich von 512 Bit berechnen und diese in einem Primrspeicher speichern. Primzahlerzeugung Das Problem der Erzeugung von sehr groen Primzahlen lsst sich etwas entschrfen, wenn man sich mit etwas weniger als 100% zufrieden gibt, wenn es also ausreicht, wenn eine Zahl mit 99,999% Wahrscheinlichkeit eine Primzahl
132
ist. Man generiert groe, ungerade Zufallszahlen und testet diese mit probalistisch arbeitenden Testverfahren, die mit einer bestimmten Wahrscheinlichkeit arbeiten. Eines der bekanntesten, schnellsten und am hufigsten implementierten Verfahren ist der Rabin-Miller-Algorithmus. Eine vollstndige Rechner-Implementierung zur Primzahlerzeugung auf Basis dieses Algorithmus fr 512-Bit-Zahlen arbeitet nach folgendem Algorithmus: 1. Erzeuge eine Zufallszahl p der Lnge 512 Bit. 2. Setze das hchst- und das niederwertige Bit von p auf 1, um die Zahl hinreichend gro und garantiert ungerade zu machen. 3. Mache einen ersten Test, ob p durch die bekannten Primzahlen von 3 bis 2000 teilbar ist. Dadurch werden bereits ber 95% aller ungeraden, nicht primen Zahlen eliminiert. 4. Falls keine Teilbarkeit besteht, wird der Rabin-Miller-Algorithmus fr p sechsmal durchlaufen. Wenn alle Tests erfolgreich waren, hat man mit hinreichender Wahrscheinlichkeit eine 512 Bit groe Primzahl p gefunden. Aufgrund der hohen Wahrscheinlichkeit von 99,999% mssen alle Angreifer (oder etwas neutraler formuliert: Kryptoanalytiker) in ihren Verfahren davon ausgehen, dass es sich tatschlich um eine Primzahl handelt wahrscheinlich ist es ja auch eine. Modulo primitiv Eine Zahl g ist modulo n primitiv, wenn es fr jedes b > 0 < n eine Zahl z gibt mit gz = b (mod n). Man nennt g auch Generator (mod n). In unserem obigen Beispiel von Diffie-Hellmann erzeugt man ein g, das modulo primitiv zu n ist, auf folgende Art und Weise: Man nimmt nacheinander Zahlen, sinnvollerweise fngt man mit sehr kleinen an, und probiert sie aus. Das dauert in der Regel nicht sehr lange, da Generatoren sehr hufig vorkommen. Relativ prim Zwei Zahlen sind relativ prim zueinander, wenn sie auer 1 keinen gemeinsamen Teiler besitzen. Die Zahlen 15 und 28 sind relativ prim zueinander, sie sind zwar keine Primzahlen, haben aber auer 1 keinen gemeinsamen Teiler. Aufgrund ihrer Natur ist eine Primzahl zu allen Zahlen, die kein Vielfaches ihr selbst sind, relativ prim. Rechnen mit Resten (Moduln) In der Kryptographie spielt die modulare Arithmetik, also das Rechnen mit Resten, eine wichtige Rolle. Praktisch kein Public-Key-Verfahren kommt daran vorbei. Ein einfaches Beispiel fr modulare Arithmetik ist unsere Armbanduhr, die die aktuelle Tageszeit Modulo 12 anzeigt: 22 mod 12 = 10, d.h.
133
es wird 10 Uhr (22 dividiert durch 12 ist 1 Rest 10) angezeigt, falls es 22:00 Uhr ist. Aber es wird auch 10 Uhr angezeigt, wenn es tatschlich 10 Uhr ist. Mathematisch ausgedrckt heit dies: 22 und 10 sind quivalent modulo 12. Allgemein ausgedrckt gilt fr alle a 0 und 0 > b < n: a = b (mod n), wenn es eine ganze Zahl k gibt, mit a = b + kn Das Ergebnis von a mod n nennt man das Residuum, die Operation selbst modulare Reduktion. Die modulare Arithmetik verhlt sind analog der normalen Arithmetik, sie ist kommutativ, distributiv und assoziativ: (a + b) mod n = ((a mod n) + (b mod n)) mod n (a * b) mod n = ((a mod n) * (b mod n) mod n Speziell im Bereich der Berechnungen in Computern sollte man sich auch folgende Beziehung vergegenwrtigen: a8 mod n = (a * a * a * a * a * a * a * a) mod n = ((a2 mod n)2 mod n)2 mod n Was macht die modulare Arithmetik fr die Kryptographie eigentlich so interessant? Schauen wir uns einmal kurz die Mathematik des weiter unten beschriebenen Diffie-Hellman-Verfahrens an. Hier wird ein Wert A durch die Funktion A = gx mod n erzeugt. Entsprechend groe x und n vorausgesetzt, handelt es sich dabei um eine Einwegfunktion, denn man kann x nicht mehr aus A zurckberechnen, auch nicht bei Kenntnis von g und n. Nehmen wir der Einfachheit halber einmal kleine Zahlen fr ein kurzes Beispiel; g soll gleich 2 und n gleich 11 sein. Die Zahl n muss eine Primzahl sein. Als Vergleich dazu nehmen wir die Funktion B = gx, also die gleiche Exponentiation, jedoch ohne modulare Reduktion. Diffie-Hellman erlaubt es, alle Werte auer der geheim zu haltenden Zahl x zu verffentlichen. Somit haben wir zwei Funktionen, A = 2x mod 11 und B = 2x. Das Ziel eines Angriffs auf das Verfahren ist es, den geheimen Wert x zu ermitteln, alle anderen Werte sind ja bekannt. Das Verfahren, x bei der Funktion B = gx zu ermitteln ist einfach. Nehmen wir einmal den Fall, dass x = 6 und damit B = 64 wre. Man whlt eine Hilfszahl h und whlt einen mglichen Wert dafr aus, zum Beispiel 4, und rechnet 24 = 16. 16 ist kleiner als 64, also wird h hher gewhlt, z.B. 8, und man rechnet 28 = 256. Dieser Wert ist grer als 64, also muss der Wert x dazwischen liegen. Man nimmt einen Zwischenwert, und mit h = 6 ergibt sich 26 = 64, und schon man hat den Wert x gefunden. Dies ist durch den stetigen Verlauf der Funktion B = 2x mglich, denn es gilt immer, dass bei einem x > y auch 2x > 2y ist. Die maximale Zahl der Schritte dieses Algorithmus lsst sich genau festlegen, denn fr eine n Bit lange Zahl bentigt man maximal n Schritte.
134
Mit der modularen Reduktion wrde die Funktion Folgendes ergeben: B = 26 mod 11 = 9. Man wrde auch hier h = 4 whlen und rechnet 24 mod 11 = 5. 5 ist kleiner als 9, also whlt man x grer, z.B. gleich 8. 28 mod 11 = 3. Das Ergebnis ist jedoch, trotz grerem h, kleiner geworden was nun? Hier versagt unser einfacher Algorithmus schon, denn man wei an diesem Punkt nicht mehr, ob man das nchste h jetzt grer oder kleiner whlen soll. Wo liegt der fundamentale Unterschied beider Funktionen? Dies wird vielleicht am schnellsten klar, wenn man deren Graphen einmal vergleicht. In Abbildung 4.19 sehen Sie, dass der Verlauf der Funktion gx (mod n) sehr unstetig zwischen den Werten 0 und n-1 schwankt ganz im Gegensatz zur stetig ansteigenden Funktion gx.
y = 2X
256 128 64 32 16 8 4 2
y = 2X (mod 11)
10 8
6 4 2
1 2 3 4 5 6 7 8
Abbildung 4.19: Die Graphen der Funktionen
y=2x
und y=
2x
(mod 11) im Vergleich
135
Dies ist nur ein einfaches Beispiel, und auch das Beispiel mit der modularen Reduktion wre noch kein Problem. In der Praxis verwendet man jedoch Zahlen ganz anderer Grenordnung. Das im IKE-Protokoll (siehe Kapitel 8) eingesetzte Diffie-Hellman-Verfahren fordert fr n eine streng getestete Primzahl von mindestens 768 Bit Lnge und empfiehlt fr x eine Zahl mit mindestens 160 Dezimalstellen mit x < n. Die Eulersche Totientenfunktion Das Resultat der Eulerschen Totientenfunktion (n) ist die Anzahl von positiven ganzen Zahlen kleiner n, die relativ prim zu n sind. Falls die Zahl n eine Primzahl ist, sind alle Zahlen kleiner n relativ prim, also ist in diesem Fall (n) = n 1. Falls die Zahl keine Primzahl, jedoch das Produkt zweier Primzahlen p und q ist, dann gilt (n) = (p) * (q) = (p 1)(q 1). Der Satz von Euler, der auf dem Satz von Fermat beruht, besagt, dass fr alle x, die relativ prim zu n sind, gilt: x(n) = 1 mod n. Inverse Elemente und Fermats Theorem Multiplikativ inverse Elemente sind in normalen Zahlensystemen, wie den rationalen Zahlen, leicht zu finden. Das inverse Element zu a ist die Zahl x, die mit a multipliziert 1 ergibt, also a * x = 1 oder x = 1/a oder x = a-1. Es existiert zu jedem Element ein inverses Element. Bezglich der modularen Arithmetik sieht dies etwas anders aus, es kann sogar so sein, dass zu bestimmten Zahlen berhaupt kein inverses Element existiert. Fermats Theorem besagt, dass fr alle Primzahlen p und alle Zahlen a < p gilt: ap mod p = a oder ap-1 mod p = 1. Wenn wir nun das inverse Element x suchen mit ax mod p = 1, dann kann man, wenn p eine Primzahl ist und a < p ist, Fermats Theorem benutzen. Denn es gilt: ap-1 mod p = 1 und ax mod p = 1 zur Bestimmung des inversen Elements. Diese beiden Gleichungen kann man kombinieren zu: ax mod p = ap-1 mod p Und x = ap-2 mod p
4.9
Das Diffie-Hellman-Verfahren
Das Diffie-Hellman-Verfahren ist der Urvater der Public-Key-Kryptographie. Es kann nicht zum Ver- und Entschlsseln von Daten benutzt werden, sondern nur zur Erzeugung von symmetrischen Schlsseln. Es basiert auf dem Problem, dass eine Exponentiation mit wenig Aufwand durchfhrbar ist, die Um-
136
Das Diffie-Hellman-Verfahren
kehrung davon, das Auffinden des Logarithmus, jedoch sehr viel lnger dauert. Ein schwieriges mathematisches Problem wird daraus, wenn es sich dabei auch noch um den diskreten Logarithmus handelt. Die Funktion z = gx mod n ist schnell zu berechnen, die Rckberechnung von x aus z ist jedoch sehr langwierig. Wieso ist x aus gx mod n sehr viel schwerer zu bestimmen als aus gx? Den gesuchten Wert von x bestimmt man fr die Funktion gx mit Hilfe einer schrittweisen Approximation aus dem Wert z, indem man eine Hilfszahl p mit einem Startwert annimmt, gp berechnet und mit z vergleicht. Ist z grer, probiert man ein greres, im anderen Fall ein kleineres p aus und nhert sich auf diese Weise dem gesuchten Wert. Dieser ist gefunden, wenn gp = z ist, und man bentigt maximal so viele Schritte, wie die Zahl x an Bit-Stellen aufweist. Im Fall der Funktion gx mod n ist die Sache so nicht zu machen, denn aufgrund der sehr unsteten Funktion kann man nicht sagen, ob man, falls gp mod n grer als z ist, p vergrern oder verkleinern muss beides ist gleich wahrscheinlich. Diese Schwierigkeit macht man sich beim Diffie-Hellman-Verfahren zunutze, denn selbst bei bekanntem z, n und g, ist x nicht in sinnvoller Zeit errechenbar. Einen Schlsseltausch kann man in folgender Weise realisieren: Die Gegenstellen A und B mchten sich auf einen symmetrischen Schlssel einigen. Jeder erzeugt fr sich zu diesem Zweck eine sehr groe Zufallszahl und hlt sie geheim. A benutzt zwei Hilfszahlen, die Zahl g und die Zahl n, eine sehr groe Primzahl. In der Praxis, zum Beispiel im IKE-Protokoll sind g und n im Standard festgelegt, somit allgemein bekannt und brauchen nicht mehr explizit bertragen zu werden. A berechnet a = gx mod n und schickt a (sowie gegebenenfalls g und n) zu B. B berechnet b = gy mod n und schickt b zu A. A berechnet k = bx = (gy mod n)x = gyx mod n. B berechnet k = ay = (gx mod n)y = gxy mod n. Da gyx mod n = gxy mod n, ist auch k = k, und beide Seiten haben somit einen identischen Schlssel. Jemand, der die bertragung von a, b, g und n abgehrt hat, kann trotzdem ohne die Kenntnis wenigstens eines der beiden geheimen Werte x und y den Schlssel nicht berechnen. Um das Diffie-Hellman-Verfahren sicher zu machen, mssen diese Zahlen gewissen Bedingungen gengen. Die Zahl n muss eine sehr groe, zuverlssig getestete Primzahl sein. blich sind Lngen von 768 oder 1024 Bit; manchmal verwendet man auch noch grere Zahlen. Fr g nimmt man meist den Wert 2. Die geheimen Werte x und y sollen auch sehr gro sein, mssen aber stets kleiner als n sein. Sie sollten durch Zufallsgenera-
137
toren oder sehr gute Pseudo-Zufallsgeneratoren erzeugt werden und nach der Berechnung der symmetrischen Schlssel vernichtet werden. Die Qualitt und Vertraulichkeit von x und y, den privaten Diffie-Hellman-Werten, ist kritisch fr den gesamten Schlsseltausch. In praktischen Implementierungen des Diffie-Hellman-Verfahrens, zum Beispiel dem IKE-Protokoll, sind die Werte n und g in einem Standard festgelegt und verffentlicht. Sie mssen aus diesem Grund nicht mehr explizit beim Schlsseltausch bertragen oder gar von einer Seite vorher noch berechnet werden.
4.10 Das RSA-Verfahren

Etwa ein Jahr, nachdem Whitfield Diffie und Martin Hellman durch ihre Arbeit frischen Wind, um nicht zu sagen Sturm, in die Kryptologie-Szene gebracht hatten, gingen drei Forscher an der Ostkste der USA mit einer weiteren bahnbrechenden Arbeit an die ffentlichkeit. Die Professoren Ronald Rivest, Adi Shamir und Leonard Adleman vom Massachusetts Institute of Technology stellten das nach ihnen benannte RSA-Verfahren vor. Der wesentliche Unterschied zum Diffie-Hellman-Verfahren ist der, dass man mit RSA Daten verund entschlsseln konnte. Denn die drei Wissenschaftler hatten das gefunden, was Whitfield Diffie und Martin Hellman bereits ein Jahr zuvor postuliert hatten: eine Einwegfunktion zur Verschlsselung und die dazugehrige Falltr-Funktion zur Entschlsselung. Die Funktion von RSA beruht auf einem anderen mathematischen Problem als das Diffie-Hellman-Verfahren, nmlich auf der Schwierigkeit, eine groe Zahl in ihre Primfaktoren zu zerlegen. Denn es ist einfach und schnell durchfhrbar, aus den beiden groen Primzahlen p und q die Zahl n = pq zu berechnen. Die Umkehrung, also nur vom Wert n ausgehend, die zwei Primzahlen zu finden, die miteinander multipliziert n ergeben, ist ein hartes mathematisches Problem. Wie funktioniert nun das RSA-Verfahren genau? Das Tupel {n,e} bildet den ffentlichen Schlssel und das Tupel {n,d} den privaten Schlssel, von dem offensichtlich d nur der tatschlich geheime, private Teil ist, da n auch Teil des ffentlichen Schlssels ist. Die Transformation des Klartexts M in den Chiffretext C erfolgt mit dem ffentlichen Schlssel {n,e} durch: C = Me mod n. Die Entschlsselung erfolgt mit dem privaten Schlssel {n,d}: M = Cd mod n.
138
Das RSA-Verfahren
Man kann beide Funktionen auch als M = (Me)d mod n zusammenfassen. Das Schlsselpaar {n,e} und {n,d} wird wie folgt berechnet: Die Zahl n ist das Produkt zweier groer, mglichst vergleichbar langer Primzahlen p und q: n = pq. Anschlieend whlt man e derart, dass es relativ prim zu (p 1)(q 1) ist. Hier kann man sich ohne lange Berechnungen und Tests geeignete Zahlen aussuchen, indem man Primzahlen whlt, die ungleich p und q sind, was fr kleine Primzahlen der Fall ist. Fr besonders schnelle Berechnungen whlt man sehr kleine e, zum Beispiel 3, 17 oder 216 +1 (65537). Diese Primzahlen wurden mit Bedacht gewhlt, denn sie sind hervorragend geeignet, um mit ihnen binre Exponentiationen durchzufhren, da sie, aus binrer Schreibweise gesehen, nur aus zwei Einsen und sonst nur Nullen bestehen. Die binre Schreibweise der Primzahl 65537 ist zum Beispiel 1000000000000001. Der private Schlsselteil d, der relativ prim zu n sein muss, wird ber den erweiterten Euklidschen Algorithmus bestimmt: ed = 1 mod ((p-1)(q-1) Nach der Berechnung von d mssen p und q zuverlssig vernichtet werden. Wenn diese beiden Primzahlen nicht mehr bekannt sind, kann man auch d nicht mehr bestimmen. Man msste aus der ffentlichen Zahl n ihre beiden Primfaktoren p und q zurckberechnen was aber ein hartes mathematisches Problem darstellt. Die mathematischen Zusammenhnge sind beim RSA-Verfahren etwas komplexer als beim Diffie-Hellman-Algorithmus. Die folgende Beschreibung geht nicht sehr ins Detail, wer tiefer in die Materie einsteigen mchte, dem seien weiterfhrende Bcher zur Zahlentheorie und Kryptographie empfohlen. 1. Wir haben gesehen, dass folgender Zusammenhang gilt: C = Me mod n, M = Cd mod n und (Me)d = M mod n. Da (Me)d = Med, zerlegt man den Exponenten gewissermaen in einen ffentlichen Teil e und einen privaten Teil d. 2. Die Zahl n wurde erzeugt, indem man zwei groe Primzahlen p und q miteinander multipliziert hat. Da p und q prim sind, gilt fr sie die Eulersche Totientenfunktion (n) = (p 1)(q 1). 3. Da e und d bezglich mod (n) invers sein mssen, damit der obige Zusammenhang gltig ist, gilt ed = 1 mod (n), und man kann ein k bestimmen, mit ed = k (n) + 1. 4. Nach dem Theorem von Fermat gilt Mp-1 = 1 mod p. Da (p-1) einer der beiden Faktoren von (n) ist, kann man auch Mk(n) = 1 mod p schreiben. Wenn wir beide Seiten der Gleichung mit M multiplizieren, erhalten wir Mk(n) + 1 = M mod p.
139
5. Das gleiche kann man auch fr die zweite Primzahl q durchfhren und erhlt analog dazu Mk(n) + 1 = M mod q. 6. Nach (1) gilt (Me)d = Med = M mod n. Nach (3) gilt weiterhin ed = k (n) + 1. Somit gilt Med = Mk (n) + 1 = M mod n. Nach (4) und (5) gelten Mk(n) + 1 = M mod p und Mk(n) + 1 = M mod q. Also gilt auch M mod p = M mod q = Mk (n) + 1 = M mod n. Da wir gesehen haben, dass ed = k (n) + 1 ist, ist auch Med = (Me)d = M mod n. Bei sachkundiger Implementierung sind noch keine praktikablen Angriffe gegen RSA bekannt geworden, die einfacher sind als eine Faktorisierung von n. Die ganzen bisher bekannten Angriffe waren gegen (manchmal nicht optimale) Implementierungen von RSA gerichtet und nicht gegen den RSA-Algorithmus selbst. Falls man alle Richtlinien beachtet und entsprechende ProgrammierToolkits, zum Beispiel das von RSA Data Security, einsetzt, kann nach heutigen Erkenntnissen beim Einsatz eines hinreichend groen n nichts schief gehen.
4.10.1
Zufallszahlen
Das Thema Zufallszahlen ist Gegenstand einer Reihe von Bchern und auch von RFCs der Internet Engineering Task Force (IETF). Gemeinhin ist es nicht schwer, eine zufllige Zahl zu erzeugen, man kann zum Beispiel wrfeln oder Roulette spielen. Es ist aber weitaus schwieriger, auf einem Computer eine echte oder dem sehr nahe kommende Zufallszahl zu erzeugen. Das liegt daran, dass ein Computer aufgrund seiner Programmierung nur vorherbestimmte Dinge tut, auch wenn einem das angesichts des Verhaltens moderner PCBetriebssysteme manchmal recht unglaublich erscheint. Aber es ist eine Tatsache, dass Pseudo-Zufallszahlen so nennt man solche Gren, die durch Computerprogramme erzeugt wurden sehr schwach sind und oft mit einem berschaubaren Aufwand rekonstruiert werden knnen. Solche Programmfunktionen fast jede Programmiersprache oder Programmierumgebung hat eine RND-Funktion (Random Function) basieren auf einem sich wiederholenden Muster, das auf einem jedes Mal anderen Startwert basiert. Kennt man diesen Startwert oder kann man ihn ungefhr abschtzen, so kann man auch die Zufallszahl(en) mit einigem Aufwand rekonstruieren. Aber auch in einem Computer gibt es Dinge, die nicht so einfach rekonstruierbar sind und eine starke Zufallskomponente haben. Die mittlere Zugriffszeit von Festplattenlaufwerken, der Inhalt des Arbeitsspeichers und vieles mehr kann schon eine gute Grundlage bilden. Nimmt man mehrere solche Werte, fgt sie zusammen und benutzt sie als Eingangsvariablen fr eine Hashfunktion, so ist das Ergebnis schon eine sehr gute Pseudo-Zufallszahl. Da man in der Regel nicht alle paar Millisekunden neue Zufallszahlen bentigt, ist der Aufwand einer solchen Methode durchaus vertretbar.
140
Hashfunktionen
Am sichersten sind solche Zufallsgeneratoren, die ihre Ausgabe durch Messung von wirklich zuflligen Naturphnomenen erzeugen, zum Beispiel anhand von Halbleiterrauschen oder der kosmischen Strahlung. Dafr bentigt man natrlich spezielle Hardware, die solche Ereignisse in digitale Werte umwandelt. Diese ist in Standardrechnern wie PCs, Workstations usw. bisher werksseitig nicht eingebaut und kann nur in Form eines Zusatzmoduls eingesetzt werden. Jedoch ist es gut mglich, dass in wenigen Jahren ein HardwareZufallsgenerator-Chip in jedem Chipsatz von PC-Motherboards enthalten ist, zusammen mit RSA-, Diffie-Hellman- und AES-Chips.
4.11 Hashfunktionen
Hashfunktionen sind keine Funktionen, die sich zum Ver- oder Entschlsseln eignen. Sie werden manchmal auch als Einweg-Kompressionsfunktionen bezeichnet, weil sie aus einem groen, beliebig langen Eingangswert einen kurzen Ausgangswert fester Gre berechnen. Man kann solche Werte benutzen, um Datenbankindizes oder Prfsummen zu erzeugen. Hashfunktionen, vor allem solche, die in der Sicherheitstechnologie Verwendung finden, sollen im Allgemeinen folgenden Eigenschaften gengen: Es soll einfach und somit auch schnell mglich sein, aus einem beliebig langen Eingangswert M einen Hashwert h der endlichen Gre n zu erzeugen. Es soll unmglich sein, aus diesem Hashwert h den zugehrigen Eingangswert M zu berechnen. Es soll unmglich sein, zu einer gegebenen Nachricht M eine Nachricht M zu berechnen, die den gleichen Hashwert erzeugt, den auch die Nachricht M erzeugt. Dies sind die grundstzlichen Designkriterien. Die ersten beiden sind leicht zu implementieren, beim letzten jedoch drngt sich Ihnen bestimmt die Frage auf, ob dies berhaupt mglich ist. Hierber streiten sich die Gelehrten, jedoch so viel sei gesagt: Eine Berechnung als solche ist nicht mglich, es gibt keine Formel, keinen Algorithmus, der aus einer beliebigen Nachricht M eine andere Nachricht M berechnet, so dass beide den gleichen Hashwert haben. Jedoch kann man eine Nachricht M finden, die den gleichen Hashwert der Nachricht M hat. Dies ist auch offensichtlich, denn die Nachricht M kann beliebig lang sein und kann unendlich viele Werte annehmen. Der Hashwert hat eine endliche Gre, in der Praxis findet man Werte zwischen 128 und 256 Bit. Somit ist die Menge der Nachrichten M, die den gleichen Hashwert erzeugen auch unendlich gro man muss nur eine finden. Ein solches Ereignis nennt man Kollision. Fr den unten beschriebenen MD5-Algorithmus wurden schon Kollisionen gefunden, fr andere Verfahren wie SHA oder RIPEMD noch nicht.
141
Somit ist noch ein anderes Designkriterium von Wichtigkeit, nmlich dass kleinste Differenzen in der Nachricht M sehr groe nderungen im Hashwert h erzeugen mssen. Meist fordert man, dass sich im Hashwert 50% aller Bits ndern, falls sich in der Nachricht M nur ein Bit verndert hat. ndern sich jedoch sehr viele Bits in der Nachricht oder ndert sich auch ihre Lnge, dann kann das Ausma der nderung im Hashwert ruhig kleiner werden, da sich in diesem Fall die Natur und der Inhalt der Nachricht erheblich gendert haben. Diese nderungen sind auf anderen Ebenen wie der Applikationsoder Darstellungsschicht im Fall von Datenbertragungen leicht erkennbar.
4.11.1
Algorithmen
Es gibt eine ganze Reihe von Hashalgorithmen, von denen hier zwei vorgestellt werden. Die Auswahl fiel deshalb auf die beiden im Folgenden beschriebenen Algorithmen, weil sie im IPSec-Standard als obligatorische Verfahren festgelegt wurden. Message Digest 5 (MD5) Dieses Verfahren kennen die meisten, zumindest vom Namen her. Es ist nicht nur in IPSec zu finden, sondern auch in allen mglichen anderen Protokollen wie CHAP, OSPF, L2TP, und es gibt sogar PC-Versionen davon, um Dateien auf Vernderungen zu berprfen. MD5 wurde vom Kryptologie-Guru Ron Rivest entwickelt und ist im RFC1321 inklusive seines C-Quellcodes beschrieben. Der Aufbau von MD5 soll hier nicht zu sehr vertieft werden. Das Verfahren erzeugt aus einem Eingangswert beliebiger Lnge einen 128-Bit-Hashwert. Neben dem Eingangswert selbst geht auch die Lnge des Wertes in die Berechnung des Hashwerts mit ein. In Abbildung 4.20 sehen Sie das Ergebnis der MD5-Funktion, die auf die beiden Texte angewendet wurde, die sich nur um einen Buchstaben unterscheiden. Die beiden Hashwerte h und h sind sehr unterschiedlich, whrend man den Unterschied der beiden Texte beim ersten Hinsehen vielleicht gar nicht bemerkt.
WISSEN IST MACHT
WISSEN IST NACHT
MD 5
MD 5
3eb9c0237f40bbb5f9b6e9bd9d2 c53d4323a0d963648fb2e6ec6e5
Abbildung 4.20: Die MD5-Funktion erkennt kleinste Abweichungen in den beiden Nachrichten.
142
Hashfunktionen
Secure Hash Algorithm (SHA) Der Secure Hash Algorithm (SHA) ist ein neueres Verfahren, das einen greren Hashwert als MD5 erzeugt. Es wird sehr oft als besser als MD5 bezeichnet. Dies liegt vor allem an seinem internen Aufbau, seiner greren Anzahl an Verarbeitungsrunden und dem hheren Lawineneffekt, der durch verbesserte Rckkopplungsfunktionen erreicht wurde. Auch sind bisher keine Kollisionen bekannt geworden. Andererseits misstrauen viele Anwender dem Algorithmus, da seine Entwicklung mageblich von NSA beeinflusst wurde und seine Entwurfskriterien nicht offen gelegt wurden. SHA ist im FIPS-PUB 1801 (Secure Hash Standard) beschrieben. Er erzeugt einen 160 Bit langen Hashwert aus einem beliebig langen Eingangswert.
4.11.2
Keyed Hashing
Hashverfahren bieten sich an, um die Integritt von Nachrichten zu schtzen. Wenn der Sender den Hashwert einer Nachricht berechnet und der Empfnger dies mit der von ihm erhaltenen Nachricht tut, dann kann er beide Hashwerte miteinander vergleichen, um zu prfen, ob die Nachricht whrend des Transports verndert wurde. Aber wie kommt der Empfnger zum Hashwert des Senders? Eine elegante Art wre es, den Hashwert einfach mit der Nachricht mitzuschicken. In diesem Fall wre aber kein Schutz mehr gegeben. Denn ein Angreifer knnte sowohl die Nachricht ndern als auch den Hashwert neu berechnen. Dies kann man verhindern, indem man so genannte Keyed-HashFunktionen verwendet. Solche Funktionen bilden ihren Hashwert aus der Nachricht M und einem Schlssel K. Dieser Schlssel ist sowohl dem Sender als auch dem Empfnger bekannt. Jetzt kann man den Hashwert mit der Nachricht zusammen verschicken, denn ein Angreifer kann zwar immer noch die Nachricht verndern, aber ohne den passenden Schlssel kann er den Hashwert nicht mehr neu berechnen, und der Empfnger wrde sofort anhand der unterschiedlichen Hashwerte die nderung bemerken
4.11.3
Hash-based Message Authentication Code (HMAC)
Nachdem nun die Hashfunktionen selbst durch symmetrische Schlssel sicher gegen nderungen bzw. Neuberechnungen geworden sind, fehlt nur noch eine Verbesserung, um sie resistenter gegen Kollisionen zu machen. Zu diesem Zweck wurde das HMAC-Verfahren entwickelt. Es ist kein Hashalgorithmus, sondern es kombiniert existierende Verfahren wie MD5 oder SHA mit symmetrischen Schlsseln und einem speziellen Padding, um auf diese Weise ein starkes Verfahren zur Authentifizierung und Integrittsprfung zu erhalten. In Abbildung 4.21 ist das Verfahren in Verbindung mit dem MD5Algorithmus zu sehen. Die HMAC-Verfahren gelten in der Fachwelt als sicher vor Kollisionen, auch wenn das zugrunde liegende Hashverfahren dies nicht ist. Auf diese Weise kann man auch einen Veteranen wie MD5, fr den schon
143
Kollisionen gefunden wurden, weiterhin verwenden, und seinen Geschwindigkeitsvorteil gegenber anderen Algorithmen ausnutzen..
Nachricht Inner-Pad Schlssel
MD 5
Outer-Pad
MD5-Hash (128 Bit)
MD 5
MD5-Hash (128 Bit)
HMAC-MD5
Abbildung 4.21: HMAC-MD5 eliminiert die Kollisionsgefahr von MD5.
144
Authentifizierung
Die Authentifizierung als solche muss man im Hinblick auf ihren Einsatz in virtuellen privaten Netzen in zwei verschiedene Klassen unterteilen: Die Authentifizierung einer natrlichen Person. Hierbei wird versucht, die Identitt einer nicht persnlich anwesenden Person durch verschiedene Methoden festzustellen. Falls beispielsweise ein Anwender ber ein Remote-Access-VPN Zugriff auf sein Unternehmensnetzwerk wnscht, muss er einem Zugangs-Kontrollsystem nachweisen, dass er auch tatschlich der ist, der er (durch die Eingabe seiner User-ID in eine Anmeldemaske) zu sein vorgibt. Die Authentifizierung von bertragungseinheiten eines Netzwerkprotokolls, um bestimmte Angriffe wie Spoofing oder Man-in-the-Middle abzuwehren. Hier soll der Absender (ein VPN-Gateway oder ein Router) eines Pakets zweifelsfrei identifiziert werden. Dieser Prozess ist meist zweistufig: Die erste Stufe ist der Verbindungsaufbau, whrend dessen sich Gegenstellen gegenseitig identifizieren, und in der zweiten Stufe, der Datenbertragungsphase, werden die Pakete daraufhin berprft, ob sie auch wirklich von der Gegenstelle kommen, zu der die Verbindung aufgebaut wurde. Diese beiden Formen der Authentifizierung darf man nicht miteinander verwechseln, da ihr jeweiliges Ergebnis vllig unterschiedliche Aussagen macht. Verbindet man zum Beispiel zwei Netzwerke ber IPSec-Security-Gateways miteinander, so authentifizieren sich zwar die Systeme gegenseitig und ebenso wird jedes bertragene Paket berprft aber ber die Benutzer in diesen Netzen gibt das Ganze keinerlei Aufschluss. Es kann jedoch in bestimmten Fllen vorkommen, dass man beide Verfahren sinnvoll miteinander kombinieren kann. Ein Beispiel ist das IKE-Protokoll, das innerhalb der IPSec-Protokollfamilie dazu benutzt wird, eine Verbindung aufzubauen und die beteiligten Gegenstellen zu authentifizieren. Falls eine dieser Gegenstellen ein Einzelplatzsystem ist, kann man die Authentifizierung des Benutzers mit der Authentifizierung des betreffenden Systems gleichsetzen und durch eine Kombination der notwendigen Verfahren sowohl den Benutzer als auch seinen Rechner authentifizieren.
145
5 Authentifizierung
5.1
Mglichkeiten der Authentifizierung
Es gibt eine ganze Reihe verschiedener Verfahren und Technologien, um Personen oder Systeme zu authentifizieren. Diese Verfahren haben eine unterschiedliche Strke hinsichtlich ihrer Beweiskraft. Praktisch alle Verfahren sind mit einem geeigneten Aufwand zu berlisten; die Authentifizierung macht also in Wirklichkeit diesen Aufwand so hoch, dass er einem potenziellen Angeifer nicht mehr vertretbar erscheint. Selbst biometrische Verfahren oder eine persnliche Anwesenheit, Verfahren, die man oft als absolut sicher bezeichnet, sind in Wirklichkeit nicht hundertprozentig sicher: Denken Sie nur an eineiige Zwillinge oder die Mglichkeiten plastischer Chirurgie. Die unterschiedlichen Authentifizierungsverfahren beurteilt und klassifiziert man nach ihrer Beweiskraft und unterteilt sie in so genannte schwache oder starke Verfahren.
5.1.1
Starke und schwache Authentifizierung
Eine starke Authentifizierung erbringt den tatschlichen Nachweis der Identitt durch berprfung der persnlichen Anwesenheit. Eine schwache Authentifizierung beweist, dass die betreffende Person etwas wei oder etwas hat, das normalerweise nur die tatschlich zugangsberechtigte Person kennt oder besitzt. Insofern haben die verschiedenen Authentifizierungsverfahren eine unterschiedliche Strke.
5.1.2
Wissensbasierende Authentifizierung
Im einfachsten Fall, der wissensbasierenden Authentifizierung, kennen der Benutzer und das Zugangskontrollsystem gemeinsam ein Geheimnis das Passwort oder Kennwort. Das heit, ein Benutzer meldet sich beispielsweise bei einem Remote-Access-Konzentrator oder einem VPN-Konzentrator unter Angabe seiner Benutzer-ID und seines Passworts an, woraufhin dieser die Richtigkeit der Angaben durch Vergleich mit seinen gespeicherten Daten berprft und daraufhin eine Verbindung entweder aufbaut oder ablehnt. Da in der Vergangenheit keine Alternativen zur Verfgung standen, ist das Passwort-Verfahren die am weitesten verbreitete, aber auch die am wenigsten sichere Methode der Benutzer-Authentifizierung. Die Schwachstellen sind: schlecht gewhlte Passwrter (z.B. die Verwendung von Eigennamen oder zu kurzen Kennwrtern), das Aufschreiben von Kennwrtern, die Weitergabe an Dritte oder zu viele verschiedene Kennwrter fr ein und denselben Benutzer, wenn er Zugang zu mehreren Ressourcen bentigt. Nur eine stndige Benutzer-Erziehung zum richtigen Passwort-Verhalten kann diese Schwchen mildern, sie kann diese aber niemals vollstndig eliminieren. Bei lokalen Zugriffen auf Netzwerke oder Systeme kann das Passwort-Verfah-
146
ren durch zustzliche organisatorische oder technische Manahmen, wie Zugangskontrollsysteme zu Gebuden oder Rumen bzw. durch die Einschrnkung der Netzanmeldung auf bestimmte Stationen, untersttzt werden.
5.1.3
Besitzbasierende Authentifizierung
Man hat die Schwchen der wissensbasierten Authentifizierung schon recht frh erkannt und nach Alternativen gesucht. Die besitzbasierende Authentifizierung ist eine davon. Bei diesem Verfahren besitzt der zugriffsberechtigte Anwender etwas, das ihn am Zugangskontrollsystem authentifiziert. Dies kann eine Chipkarte oder auch eine so genannte Token-Karte sein, die dem Benutzer eindeutig zugeordnet wurde und einmalig ist. Der Benutzer erhlt Zugang oder keinen Zugang, indem das Kontrollsystem die auf der Karte gespeicherten Informationen, die dem Benutzer eindeutig zugewiesen sind, liest und mit den eigenen Daten vergleicht. Dieses Verfahren wird als sicherer als das Passwort-Verfahren angesehen, weil solche Karten nur wenn berhaupt mit einem gewissen Aufwand zu duplizieren sind. Probleme entstehen allerdings bei Verlust oder Diebstahl. Also ist auch dieses Verfahren noch weit davon entfernt, eine zuverlssige Authentifizierung zu gewhrleisten.
5.1.4
Kombinationsverfahren
Den nchsten Grad an Sicherheit erreicht man durch die Kombination der ersten beiden Varianten, wie Sie sie in Abbildung 5.1 sehen. Das heit, dass der Anwender sowohl einen Gegenstand, z.B. eine Chipkarte, besitzt als auch ein Passwort oder eine PIN (Persnliche Identifikationsnummer) kennt und dass er sich mit beiden gleichzeitig ausweisen muss. Nur die Karte bzw. nur das Passwort oder die PIN allein reicht nicht aus. Ein Beispiel hierfr, das wir alle kennen, sind die Geldautomatenkarten. Sein Geld aus einem Geldautomaten bekommt man nur durch den Nachweis des Besitzes der Karte und die Kenntnis der damit verbundenen geheimen PIN. Nur mit der PIN oder der Karte allein geht man leer aus.
PIN (Wissen)
Wissensbasierende Information (PIN, Passwort, ...)
Zugangskontrollsystem
Besitzbasierende Information (Token, Chipkarte, ...)

berprfung der Besitzund Wissensinformationen
Chipkarte (Besitz)
Abbildung 5.1: Die Kombination von wissens- und besitzbasierender Authentifizierung
147
5 Authentifizierung
5.1.5
Biometrik
Die strkste Art des Nachweises der persnlichen Identitt eines Benutzers kann entweder durch die berprfung der persnlichen Anwesenheit, z.B. durch eine Live-Bildbertragung bei der Netzanmeldung, oder durch biometrische Verfahren wie Fingerabdruck-Leser, DNS-Analysator oder Augennetzhaut-Scanner erbracht werden. Solche Authentifizierungsverfahren sind sehr stark, weil sie nur mit erheblicher krimineller Energie auer Kraft gesetzt werden knnen. Sie sind heute allerdings noch nicht in groer Stckzahl im Einsatz, weil sie entweder noch nicht serienreif sind oder eine breite Anwendung, z.B. von Bildbertragungssystemen an jedem Arbeitsplatz, noch zu teuer ist. Aufgrund der groen Nachfrage nach sehr sicheren Authentifizierungsverfahren und der sich abzeichnenden Erfolge, z.B. bei der Entwicklung von kostengnstigen Fingerabdruck-Lesern, drfte diesen Verfahren aber die Zukunft gehren. Allerdings sind einige dieser Verfahren allein auch noch sehr schwach. Es stellt beispielsweise kein groes Problem dar, sich von einer Person Fingerabdrcke zu beschaffen man hinterlsst ja genug. Auch hier ist die Kombination von biometrischen Verfahren mit anderen erforderlich.
5.1.6
Verfahren mit Einmal-Token
Eine besonders sichere Variante stellen Token-Karten dar, die einen so genannten Einmal-Code (One-Time-Token) erzeugen, wie zum Beispiel das SecurIDVerfahren der Firma RSA Security. Der Benutzer erhlt eine Token-Karte mit einer ihm eindeutig zugeordneten Seriennummer, eine User-ID und eine PIN. Bei der Netzanmeldung gibt er seine User-ID ein und liest die von der TokenKarte erzeugte Ziffernfolge das Token ab. Dieses gibt er, zusammen mit seiner PIN, in die Anmeldemaske ein. Diese Ziffernfolge ist nur fr eine bestimmte Zeitdauer, in der Regel eine Minute, gltig und kann nur ein einziges Mal zur Anmeldung verwendet werden. Man kann sich also in diesem Fall nur einmal pro Minute authentifizieren. Da mehrere Anmeldungen mit dem gleichen Token nicht mglich sind, stellt es auch kein Sicherheitsproblem dar, wenn ein Token nach der Authentifizierung bekannt wrde. Zur Authentifizierung werden die User-ID, das Token und die PIN zum Zugangskontrollsystem geschickt. Dieses berechnet aufgrund der aktuellen Zeit, der User-ID und der in seiner Datenbank gespeicherten PIN ebenfalls ein Token. Stimmen beide Token berein, ist der Benutzer authentisch. Dieses Verfahren ist deshalb so stark, weil bei jeder Anmeldung ein neues Token erzeugt wird und dieses Token jeweils nur eine begrenzte zeitliche Gltigkeit besitzt. Selbst wenn jemand bei der bertragung zur Gegenstelle oder beim Eintippen das Token und die PIN mitliest und die User-ID des Benutzers
148
kennt, knnen die Informationen zu einer erneuten Anmeldung nicht mehr benutzt werden. Ein Angreifer kennt dann zwar alle drei Faktoren, die zur Authentifizierung bentigt werden, aber einer dieser Faktoren, das Token, ist nur ein einziges Mal gltig und nicht vorherbestimmbar.
Benutzer
Token-Karte (Besitz)
Serien-Nr.
Serien-Nr.
Zugangskontrollsystem
Hash-Algorithmus
Benutzerdatenbank
Token
Hash-Algorithmus
PIN
Token
User-ID PIN Token
Vergleich 1
User-ID PIN Token
PIN (Wissen)
User-ID (Identifikation)
Vergleich 2
Abbildung 5.2: Eine Authentifizierung mit einer Token-Karte
In Abbildung 5.2 sehen Sie die Funktion des Token-Verfahrens im Detail. Der Benutzer besitzt eine Token-Karte und kennt seine geheime PIN. Auf der Token-Karte befindet sich eine 64 Bit groe Seriennummer, die zur Zuordnung der Karte zum Benutzer und zur Sicherstellung der Eindeutigkeit der Karte benutzt wird. Das Authentifizierungssystem hat eine Liste der Benutzer, ihrer PINs und der Seriennummern der den Benutzern zugeordneten Karten in seiner Datenbank gespeichert. Die Token-Karten und der Authentifizierungsserver mssen zeitsynchron sein. Nehmen wir in diesem Beispiel einmal an, die Clientsoftware untersttzt das Token-Verfahren nicht und bietet als Anmeldemaske ein Feld fr den Benutzernamen und das Passwort an. Dann sieht der Ablauf der Authentifizierung wie im folgenden Abschnitt beschrieben aus. Die Token-Karte erzeugt in mintlichem Abstand ein neues Token, das mit einer speziellen Hashfunktion aus der aktuellen Uhrzeit und der Seriennummer der Karte erzeugt wird. Der Benutzer liest das Token, eine mehrstellige Ziffernfolge, ab und trgt seine PIN, gefolgt vom Token in das Passwort-Feld der Anmeldemaske ein. Im Feld zur Eingabe des Benutzernamens gibt er
149
5 Authentifizierung
seine User-ID ein. Diese Informationen werden dann zum Authentifizierungssystem geschickt. Dieses fragt anhand der User-ID in seiner Datenbank die PIN und die Seriennummer der Token-Karte des Benutzers ab und berechnet aus seiner aktuellen Uhrzeit und der Seriennummer ebenfalls ein Token. Falls dieses Token und das vom Benutzer geschickte bereinstimmen, die PIN korrekt ist und das Token nicht vorher schon einmal benutzt wurde, wird der Benutzer vom System angemeldet.
5.2
Digitale Signaturen und digitale Zertifikate
Seit der Einfhrung der Public-Key-Kryptographie und der Verffentlichung des RSA-Verfahrens kann man auch digitale Signaturen zur Authentifizierung einsetzen. Die Strke dieser Authentifizierung hngt aber weniger von den eingesetzten Verfahren selbst ab als von der Art und Weise, wie die privaten und ffentlichen Schlssel verwaltet werden und wie verbindlich die Zuordnung eines ffentlichen Schlssels zu einer Person oder einem System ist.
5.2.1
Funktionsweise von digitalen Signaturen
Die Technologie, die hinter der digitalen Signatur steht, ist meist die Umkehrung der RSA-Verschlsselung, indem man etwas mit dem privaten Schlssel verschlsselt und das Ergebnis nur mit dem korrespondierenden ffentlichen Schlssel wieder lesbar machen kann. Dieses Verfahren ist offensichtlich nicht zum Schutz der Datenvertraulichkeit geeignet, da jedermann Zugang zum ffentlichen Schlssel haben kann. Der Trick dieses Verfahrens liegt darin, dass man, wenn man etwas mit dem ffentlichen Schlssel einer Person entschlsseln kann, wei, dass nur diese Person selbst die Verschlsselung vorgenommen hat, da nur sie den notwendigen privaten Schlssel besitzt. Auerdem sind aus den gleichen Grnden die entschlsselten Daten auch integer. So weit die Theorie. Um dies aber in ein praktikables und in letzter Instanz auch rechtsverbindliches Verfahren umzusetzen, mssen einige Rahmenbedingungen geschaffen werden: Die Sicherheit des privaten Schlssels Die Bindung einer Person an einen ffentlichen Schlssel Verteilung und Management der Schlssel Vertrauensbeziehungen
150
Die Sicherheit des privaten Schlssels Die Sicherheit des privaten Schlssels ist essenziell. Er darf sich nur im Besitz des Benutzers befinden. Es drfen somit auch keine Sicherheitskopien davon existieren. Der Schlssel muss offensichtlich vor dem Zugriff Dritter sicher sein. Dies kann man durch organisatorische und technische Manahmen erreichen. Ein Beispiel sind Chipkarten, auf denen der private Schlssel verschlsselt gespeichert ist. Der Schlssel kann vom Benutzer nur dann in eine durch den Signatur-Algorithmus benutzbare Form transformiert werden, wenn er die Chipkarte besitzt und das entsprechende Passwort kennt. Die Bindung einer Person an einen ffentlichen Schlssel Derjenige, der eine digitale Signatur verifizieren will, muss sicher sein knnen, dass er auch den ffentlichen Schlssel dazu benutzt, der dem Signierenden gehrt. Es muss also beispielsweise ein Verzeichnis von eindeutigen Benutzernamen mit dem zugehrigen ffentlichen Schlssel existieren. Dieses Verzeichnis muss von einer Institution verwaltet werden, die fr alle Beteiligten vertrauenswrdig ist. Verteilung und Management der Schlssel Es muss ein zuverlssiges Verfahren existieren, das die Schlssel an die Orte transportiert, an denen sie bentigt werden. Der private Schlssel sollte mglichst berhaupt nicht transportiert werden mssen, sondern am besten an dem Ort (Chipkarte, Rechner), an dem er verwendet wird, erzeugt werden. Vertrauensbeziehungen Die Verwaltung und Verteilung der ffentlichen Schlssel durch eine bestimmte Institution bedingt, dass ihr alle Beteiligten trauen. Es muss also gewissermaen eine Art Vertrauensinfrastruktur existieren, in der Folgendes zutreffen muss: 1. Die Person B vertraut der Person A. 2. Die Person C vertraut der Person A. 3. Wenn die Person B der Person A traut, traut sie dadurch auch der Person C. 4. Wenn die Person C der Person A traut, dann traut sie dadurch auch der Person B. 5. Dies gilt insbesondere auch, wenn sich die Personen B und C vorher nicht kennen.
151
5 Authentifizierung
Absender
Dokument
Empfnger
Dokument
Zertifikat
Absender
Zertifikat
Absender
MD5
Signatur
Signatur
MD5
Hash
Privater Schlssel des Absenders
ffentlicher Schlssel des Absenders
Hash
RSA
Vergleich
Hash
Signatur
RSA
Signatur
Abbildung 5.3: Eine digitale Signatur mit MD5 und RSA
Die Person A nimmt in unserem Beispiel eine besondere Stellung ein, da ihr alle trauen mssen, damit unser Beispiel funktioniert. Man nennt dies eine indirekte Vertrauensbeziehung, da sich hier B und C gegenseitig vertrauen, ohne sich kennen zu mssen. Unser Problem der Verwaltung und eindeutigen Zuordnung der ffentlichen Schlssel wird nun dadurch gelst, dass sich A des Problems annimmt. Er teilt allen Interessierten, die ihm trauen, mit, welche Person welchen ffentlichen Schlssel besitzt. Auf diesem Modell basieren alle heutigen Infrastrukturen zur Verwaltung von ffentlichen Schlsseln und digitalen Zertifikaten. In diesen Zertifikaten steht genau beschrieben, wem das Zertifikat gehrt und wie sein ffentlicher Schlssel ist. Neben dem weit verbreiteten RSA-Verfahren gibt es auch noch andere Signatur-Algorithmen und einen Digital Signature Standard (DSS), der auf dem Digital Signature Algorithm (DSA) basiert. Da die verwendeten Public-KeyVerfahren sehr langsam sind, verschlsselt man nicht die kompletten Daten, die man signieren will. Man benutzt, wie Sie in Abbildung 5.3 am Beispiel von RSA und MD5 sehen, statt dessen ein schnelles Hashverfahren und verschlsselt nur dessen Ergebnis mit dem asymmetrischen Verschlsselungsverfahren.
152
5.2.2
Digitale Zertifikate nach ITU-X.509-Standard
Wie sieht nun eigentlich ein digitales Zertifikat aus? Es soll ja die Identitt einer Person oder auch eines Systems, das ein Zertifikat benutzen soll, an dessen ffentlichen Schlssel gebunden werden. In einem Zertifikat muss also ein eindeutiger Name der betreffenden Instanz stehen, der Schlssel selbst, Informationen ber den verwendeten Signatur-Algorithmus und der Gltigkeitsbereich, sowohl zeitlich als auch hinsichtlich der Infrastruktur. Die Zertifikat-Struktur wurde von der ITU standardisiert und liegt mittlerweile in der dritten Version vor, die jedoch abwrtskompatibel ist. Ein System, das Zertifikate der Version 3 verarbeiten kann, kann auch (eine entsprechende Implementierung vorausgesetzt) Zertifikate der Version 1 verwenden, aber nicht umgekehrt. In Abbildung 5.4 sehen Sie das Format eines Zertifikats nach dem ITU X.509-Standard, den es mittlerweile in zwei, noch gleichzeitig gltigen Versionen gibt. Heute werden fast nur noch Zertifikate der Version 3 (X.509v3) eingesetzt. Die Felder haben folgende Bedeutung: Version of Certificate Die Versionsnummer des vorliegenden Zertifikats. Gltige Werte in diesem Feld sind 0 (Version 1) und 2 (Version 3). Certificate Serial Number Dieses Feld enthlt die Seriennummer des Zertifikats. Die Seriennummer ist nur innerhalb des Gltigkeitsbereichs der ausstellenden Certificate Authority (CA, siehe unten) eindeutig. Signature Algorithm for Certificate Authority Beschreibt den Signatur-Algorithmus, mit dem die Certificate Authority das vorliegende Zertifikat signiert hat. Issuer (Certification Authority) X.500 Name Hier steht der Name der ausstellenden Certificate Authority im X.500-Format. Validity Period for Certificate In diesem Feld wird die Gltigkeitsdauer des Zertifikats in Form eines Anfangs- und Ablaufdatums festgelegt. Subject X.500 Name Hier steht der so genannte Distinguished Name des Besitzers des vorliegenden Zertifikats, zum Beispiel DN=Manfred Lipp, OU=Competence Center, O=Nortel Networks, C=DE.
153
5 Authentifizierung
Digitales Zertifikat nach X.509

Version of Certificate
Certificate Serial Number
Signature Algorithm for Certificate Authority
Issuer (Certification Authority) X.500 Name
X.509v2
X.509v3
X.509v1
Validity Period for Certificate

Subject X.500 Name
Subject Public Key Information
Algorithm Identifier Public Key Value
Issuer Unique Identifier Subject Unique Identifier Extension Field (Variable)
Certification Authoritys Digital Signature
Abbildung 5.4: Ein Zertifikat nach ITU-X.509
Subject Public Key Information Informationen zum ffentlichen Schlssel des Inhabers des vorliegenden Zertifikats. Hier werden der verwendete Public-Key-Algorithmus, die Lnge des ffentlichen Schlssels und der Schlssel selbst festgelegt. Issuer Unique Identifier (nur Version 2 und 3) Dies ist eine optionale Zeichenkette, die sicherstellen soll, dass der Name der CA eindeutig ist. Subject Unique Identifier (nur Version 2 und 3) Dieser optionale String soll die Eindeutigkeit des Benutzernamens sicherstellen. Extension Field (nur Version 3) Dieses flexible Erweiterungsfeld (Extension Field), das nur in X.509 Version 3 benutzt wird, besitzt ein flexibles Format, um auch zuknftige Funktionalitten abbilden zu knnen, ohne jedes Mal den Standard ndern zu mssen. In diesem Feld werden Schlssel-, Policy- und Benutzer-Attribut-Informationen abgelegt.
154
Authentifizierungssysteme und -protokolle
Certificate Authoritys Digital Signature Digitale Signatur des vorliegenden Zertifikates mit dem privaten Schlssel der Certificate Authority.
5.3
Die in den vorangegangenen Abschnitten beschriebenen Verfahren und Technologien werden in verschiedenen Protokollen und Authentifizierungssystemen eingesetzt.
5.3.1
PAP und CHAP
Die in den vorausgegangenen Abschnitten beschriebenen Authentifizierungsverfahren werden sowohl bei der Anmeldung eines Benutzers im lokalen Netz auf dem Firmengelnde als auch von Remote-Nutzern, zum Beispiel in Auenstellen oder zu Hause, verwendet. Bei Remote-Anmeldungen spielt ein zustzlicher Faktor die bertragung ber das Weitverkehrsnetz eine Rolle. Zur Authentifizierung ber das Weitverkehrsnetz gibt es unterschiedliche Protokolle. Auf Point-to-Point-(PPP)-Verbindungen kommen zwei standardisierte Protokolle zum Einsatz, das Password Authentication Protocol (PAP) und das Challenge Handshake Authentication Protocol (CHAP). Beim PAP werden die vom Benutzer am Rechner eingegebene User-ID und das Passwort im Klartext zur berprfung an die Gegenstelle, z.B. einen Remote-Access-Konzentrator am Firmenhauptsitz, bertragen und von diesem mit den in seiner Datenbank gespeicherten Informationen verglichen. Die Echtheit des Benutzers wird bei bereinstimmung besttigt, oder der Zugriff wird verweigert. PAP wird von bestimmten anderen Authentifizierungsverfahren, z.B. SecurID und anderen Token-Verfahren und von der noch zu besprechenden Passthrough-Authentifizierung vorausgesetzt. Der Hauptnachteil dieses Verfahrens ist, dass bei einem Abhren der Leitung das Passwort im Klartext zur Verfgung steht. Wer PAP trotzdem verwendet und mehr Sicherheit will, muss zustzlich andere Verfahren, z.B. eine Leitungsverschlsselung, einsetzen. PAP in Verbindung mit einem Tokenverfahren stellt jedoch kein Sicherheitsproblem dar. CHAP ist eine Drei-Phasen-Handshake-Prozedur, in der das Kennwort nicht explizit bertragen wird, sondern als ein Eingabewert fr einen Hash-Algorithmus dient. In Abbildung 5.5 sehen Sie den Ablauf einer Benutzeranmeldung mit CHAP. Die erste Phase wird eingeleitet, sobald der Benutzer eine
155
5 Authentifizierung
PPP-Verbindung zu einem WAN-Zugangssystem, beispielsweise einem Remote-Access-Konzentrator am Firmenhauptsitz aufbaut. Als Antwort schickt dieser seine CHAP-Challenge zurck, die aus einer zuvor erzeugten Zufallszahl X und seiner eigenen Kennung, beispielsweise seinem Gertenamen, besteht. Danach wird ber eine Hashfunktion, meist MD5, aus dem Passwort und der Zufallszahl X ein 128 Bit groer Hashwert berechnet. Dieser Hashwert wird zusammen mit der User-ID des Benutzers als CHAPResponse an den RAC auf der Gegenseite geschickt. Der RAC nimmt die User-ID und berprft, ob diese mit dem zugehrigen Passwort in seiner Datenbank hinterlegt ist. Ist dies der Fall, ermittelt er aus dem hinterlegten Passwort und der Zufallszahl X ebenfalls einen Hashwert und vergleicht diesen mit dem vom Benutzer bertragenen. Stimmen beide berein, schickt der RAC eine so genannte CHAP-Success-Message, andernfalls eine CHAP-Failure-Message zurck. Bei einer CHAP-Success-Message wird eine Verbindung bis zum Ende aufgebaut, bei einer CHAP-Failure-Message wird die bestehende Verbindung sofort unterbrochen.
Benutzer Zugangskontrollsystem
Zufallsgenerator
PasswortEingabe
RND
CHAP-Challenge
X
Passwort
MD5
Benutzerdatenbank
MD5
User-ID Hash
CHAP-Response
User-ID Hash
Hash
User-ID (Identifikation)
Vergleich
CHAP-Accept/Reject
Abbildung 5.5: Das dreiphasige CHAP-Verfahren
156
Weiterhin bietet das CHAP-Protokoll die Mglichkeit, die bestehende Verbindung zu berwachen, um mgliche Angriffe durch Spoofing abzuwehren. Zu diesem Zweck kann als CHAP-Konfigurationsoption ein Zeitintervall festgelegt werden, innerhalb dessen die Authentifizierung in unregelmigen Abstnden wiederholt wird. Dadurch, dass das Passwort nicht im Klartext, sondern nur ein nicht zurckzuverfolgender Hashwert ber die WAN-Leitung bertragen und die Verbindung konstant berwacht wird, ist CHAP sicherer als PAP. Aber CHAP hat auch Nachteile. Weil das Verfahren voraussetzt, dass sowohl an der Quell- als auch an der Zieladresse das Benutzerpasswort im Klartext vorliegt, kann es nicht zusammen eingesetzt werden mit: Authentifizierungsverfahren, die berhaupt keine fr CHAP verwendbare Kennwrter benutzen, z.B. Token-Verfahren. Authentifizierungssystemen, die Betriebssystem-Accounts verwenden, denn die Passwrter knnen von den Betriebssystemen nicht mehr in Klartext umgewandelt werden. Der letzte Punkt tut besonders dann weh, wenn man netzwerkweit nur noch eine User-ID und ein Kennwort verwenden will beim so genannten SingleSign-On. Viele Remote-Access-Systeme bieten die Mglichkeit, auf die Authentifizierungsdienste von Netzwerkbetriebssystemen wie Novell, Unix oder NT zurckzugreifen, um ein bestehendes Benutzerkonto auch fr den Fernzugriff auf das Netzwerk zu benutzen. Somit msste sich der Benutzer nur ein einziges Passwort merken, und der administrative Aufwand zur Benutzerverwaltung wre ebenfalls reduziert. Aber da praktisch kein Betriebssystem in der Lage ist, ein Benutzerpasswort im Klartext zu rekonstruieren, CHAP dies aber erfordert, bleibt fr die betriebssystemgesttzte Authentifizierung nur PAP brig.
5.3.2
RADIUS
Fr Anwender, die mit einer zentralen Datenbank zur Authentifizierung arbeiten und trotzdem CHAP einsetzen wollen, bietet der Remote Authentication Dial In User Service (RADIUS) eine Alternative. RADIUS ist ein im RFC2038 und RFC2039 festgelegtes Protokoll zur Authentifizierung von Remote-Nutzern. Es ist eine Client-Server-Architektur, die fr Access-Gerte unterschiedlicher Hersteller ausgelegt ist, sofern diese Systeme einen RADIUS-Client implementiert haben. Die Authentifizierung erfolgt entweder ber eine RADIUS-eigene Datenbank auf dem RADIUS-Server oder ber die Pass-Through-Authentifizierung durch das Netzwerkbetriebssystem. Im ersten Fall sind die Benutzerdaten, also die User-IDs, Passwrter und Sitzungsattribute, in einer lokalen RADIUS-Datenbank abgelegt. Die Passwrter werden blicherweise im Klartext gespeichert; es gibt aber auch RADIUS-Server, die Passwrter verschlsseln und wieder entschlsseln knnen. Beide Datenbanktypen untersttzen sowohl PAP als auch CHAP.
157
5 Authentifizierung
Dial-In-Client
RADIUSClient
RADIUSServer
RADIUS-Protokoll
ISDN PSTN
Dial-In-Client
Remote-Access-Konzentrator
Interne Benutzerdatenbank
Abbildung 5.6: RADIUS ist eine Client-Server-Architektur.
Die Anmeldung erfolgt nach dem folgenden zweistufigen Konzept, das Sie in Abbildung 5.6 sehen: Der Benutzer baut in unserem Beispiel eine Verbindung zu einem Remote-Access-Konzentrator mit einer RADUIS-Client-Implementierung auf. Der RADIUS-Client fragt beim zentralen RADIUS-Server nach, ob sich der Benutzer anmelden darf. Der RADIUS-Server vergleicht dazu die User-ID und das Passwort und schickt im Erfolgsfall an den Remote-AccessKonzentrator ein Paket mit denjenigen Sitzungsattributen zurck, die dieser bentigt, um die Sitzung fr den betreffenden Benutzer zu konfigurieren. Diese Sitzungsattribute knnen zum Beispiel die IP-Adresse, die dem Benutzer zugewiesen werden soll, bestimmte Paket-Filter, Idle-Timer usw. sein. Man kann somit RADIUS auer zum Authentifizieren und fr das Accounting auch zur Autorisierung und zur Konfiguration der PPP-Verbindung verwenden. Das RADIUS-Protokoll legt zu diesem Zweck eine Reihe von Standardattributen und den zugehrigen Datentypen und -formaten fest und bietet auch die Mglichkeit, herstellerspezifische Attribute einzubinden. RADIUS hat sich im Remote-Access-Bereich und bei den Internet Service Providern seit Jahren schon als Standard durchgesetzt. Allerdings hat die Authentifizierung durch eine RADIUS-eigene Datenbank auch einige Nachteile, vor allem den, dass die Benutzer ihre Passwrter nicht selbst ndern knnen. Denn der RADIUS-Standard umfasst nur die AccessSysteme mit einem RADIUS-Client, den RADIUS-Server und das Kommunikationsprotokoll. Die eigentlichen Remote-Access-Clients werden nicht bercksichtigt, also gibt es auch kein Programm oder Verfahren, mit dem die Benutzer ihre Passwrter auf dem RADIUS-Server ndern knnen. Eine nderung der Kennwrter ist aber in gewissen Zeitabstnden unter Sicherheitsaspekten notwendig. Dadurch bleibt trotz des Vorteils der zentralen Speicherung und Pflege der Benutzerdaten immer noch ein gewisser Verwaltungs- und Kostenaufwand fr den Administrator bestehen, denn er muss nicht nur bei der erstmaligen Generierung, sondern auch bei jeder nderung jedem Benutzer das Passwort erneut auf eine sichere Art und Weise zuschicken.
158
Dial-In-Client
RADIUSClient
RADIUSServer
RADIUS-Protokoll
ISDN PSTN
Remote-Access-Konzentrator
Dial-In-Client
Authentifizierungsprotokol l
Authentifizierungssystem
Abbildung 5.7: RADIUS erlaubt auch eine Authentifizierung durch externe Systeme.
Anwender mit extrem ausgeprgtem Sicherheitsdenken wenden auerdem bei RADIUS-Servern, die intern verschlsselt gespeicherte Passwrter wieder entschlsseln knnen, ein, dass damit ein gewisses Sicherheitsloch entstehe. Denn ein Passwort, das von einem System zu entschlsseln sei, knne theoretisch auch von einer Person entschlsselt werden. Der letztgenannte Einwand kann nicht ausgerumt werden. Anwender, die diese Meinung vertreten, mssen auf eine zentrale RADIUS-Benutzerverwaltung verzichten und statt dessen die verteilte Datenhaltung in den RemoteAccess-Systemen akzeptieren. Die andere Schwachstelle dass Benutzer ihr Passwort nicht ndern knnen ist durch Einsatz der Passthrough-Authentifizierung auszuschalten, allerdings ist dann CHAP nicht mehr einsetzbar. Bei der Passthrough-Authentifizierung sind die Benutzerkonten im Netzbetriebssystem angelegt. Sobald der Benutzer sein Passwort in seinem Betriebssystem ndert, ist es damit auch fr seinen Fernzugriff gendert. Zur oben beschriebenen zweistufigen Anmeldung kommt bei der Passthrough-Authentifizierung eine weitere Stufe hinzu, wie Sie im Beispiel der NT-Authentifizierung in Abbildung 5.7 sehen. Der RADIUS-Server gibt die Authentifizierungsanfrage an das Netzbetriebssystem weiter, das die Benutzerdaten mit seinen Benutzerkonto vergleicht. Diese weitere Phase der Authentifizierung bringt etwas mehr Verzgerungszeit mit sich; dafr spart sie dem Administrator viel Zeit und damit Kosten bei der Passwortverwaltung. Denn in diesem Fall ist, sobald der Benutzer sein Passwort in der NT Domain verndert, damit auch gleichzeitig sein Remote-Passwort gendert. Es ergibt sich eine Vereinfachung im Passwortgebrauch, da sich der Benutzer mit der Eingabe seiner User-ID und seines Passworts sowohl am RemoteAccess-Konzentrator als auch am Netzwerkbetriebssystem anmeldet. Das
159
5 Authentifizierung
heit, er nimmt mit einem Passwort zwei Sicherheitsbarrieren auf einmal. Allerdings kann dies von Fall zu Fall mit der Sicherheitsstrategie einiger Unternehmen in Konflikt kommen, da diese gerade beim Remote Access oft eine Zweistufigkeit fordert.
5.3.3
LDAP
Das Lightweight Directory Access Protocol (LADP) nimmt eine zunehmend wichtige Rolle als Basis fr unternehmensweite Verzeichnisdienste ein. Unternehmen wie Microsoft, Novell, Sun/Netscape und viele andere benutzen diesen Standard bereits. LDAP ist kein Authentifizierungssystem im eigentlichen Sinn, es bietet diese nur als Option an, da der Benutzername und die Passwrter wichtige Attribute in einem Verzeichnisdienst (Directory Service) sind. Dienste wie LDAP zeichnen sich in guten Implementierungen unter anderem dadurch aus, dass die Lese-Zugriffe extrem schnell sind. Schreibende Zugriffe sind durch die Optimierungen gelegentlich eher langsam (das muss aber nicht sein), denn sie machen in einem produktiven Directory Service meist weniger als 1% der Datenbankzugriffe aus.
5.3.4
Chipkarten
Chipkarten werden vermutlich die Medien der Zukunft sein, wenn es um die Speicherung von digitalen Zertifikaten geht. Leider sind die Standardisierungsbemhungen noch nicht besonders erfolgreich verlaufen, so dass viele Hersteller immer noch ihre proprietre Soft- und Hardware einsetzen. Eine einzige persnliche Chipkarte, mit der man Bargeld bekommt, sich rztlich behandeln lsst, sich an einem Zugangskontrollsystem authentifiziert und Vertrge elektronisch unterschreibt, ist leider noch Zukunftsmusik. Dies liegt neben fehlenden, weltweit akzeptierten Standards auch an einer Reihe rechtlicher und internationaler Rahmenbedingungen, an denen allerdings gerade fleiig gearbeitet wird. Bei den Chipkarten nicht zu verwechseln mit einfachen Magnetkarten unterscheidet man grundstzlich zwischen Karten, die nur Daten speichern knnen, und Karten mit so genannter Eigenintelligenz. Zur Speicherung von Zertifikaten benutzt man die letztgenannte Gruppe, also Karten, die ber einen Prozessor, Programm- und Arbeitsspeicher sowie eine Ein-/Ausgabeschnittstelle verfgen. In diesen Chipkarten werden in der Regel nicht nur die privaten Schlssel der Besitzer gespeichert, sondern auch die Signatur erzeugt. Auf diese Weise verlsst der private Schlssel niemals die Chipkarte, sie bekommt nur das zu signierende Dokument zugefhrt und liefert die Signatur zurck. Dies bedeutet auch, dass die Signatur-Algorithmen auf der Karte ablaufen.
160
Kontaktflchen
1 2 3
8 7 6
4 5
EEPROM
CPU
Abbildung 5.8: Der Aufbau einer Standard-Chipkarte
Wie Sie in Abbildung 5.8 sehen, sind wenigstens die Funktionen der Pins der Kontaktflche, mit der die Karte mit der Auenwelt kommuniziert, im ISOStandard 7816-2 festgelegt. In der Regel darf der private Schlssel nicht aus der Chipkarte ausgelesen werden knnen. Die Verarbeitung der dann auf der Karte notwendigen kryptographischen Funktionen erfolgt in guten Chipkarten ber einen zweiten Prozessor (Kryptoprozessor), der auf Algorithmen wie RSA oder DES hin optimiert ist. Der Zugriff auf die Karten ist durch eine PIN oder ein Passwort geschtzt, so dass auch hier wieder eine Zwei-Faktor-Authentifizierung vorliegt. Es ist technisch sehr kompliziert, extrem aufwendig und in vielen Fllen bisher unmglich, aus Chipkarten den privaten Schlssel auszulesen. Jedoch gab es schon praktische Angriffe, bei denen beispielsweise die Werte der Speisespannung, die von auen an die Karte angelegt werden muss, gemessen werden, um Auskunft ber Zustnde von S-Boxen oder bestimmten Speicherblcken zu erhalten. Gezielte Funktionsstrungen durch Manipulationen an der Betriebsspannung oder an dem von auen zugefhrten Taktsignal sind ebenfalls Methoden, mit denen echte Angreifer und die Testlabors der Hersteller versuchen, solche Chipkarten zu knacken.
Chipkarte
Interne Struktur
1 2 3 4 5 6 7 8
= = = = = = = =
Versorgungsspannung Reset Taktsignal Reserviert Masse (0 V) Programmierspannung Ein-/Ausgabeschnittstelle Reserviert
I/O-Port (Interface)
Ein/Ausgabe
ROM
161
5 Authentifizierung
5.4
5.4.1
Public Key Infrastructure (PKI)

Vertrauensmodelle
Im Abschnitt ber digitale Signaturen wurde bereits darauf hingewiesen, dass man fr eine praktische Anwendung der Public-Key-Kryptographie zum Signieren von Daten oder zur Authentifizierung bestimmte Infrastrukturen und Vertrauensmodelle bentigt. Digitale Zertifikate, wie sie im X.509-Standard beschrieben sind, dienen dazu, die Identitt einer Person, einer Organisation oder auch die eines Security-Gateways fest mit deren ffentlichem Schlssel, dem Public Key, zu verbinden. Dies wird von einer so genannten Certificate Authority (CA) vorgenommen, einer Institution, der alle, in der von ihr verwalteten Public Key Infrastructure (PKI), Beteiligten vertrauen. Direkte Vertrauensbeziehungen Nehmen wir zuerst einmal den anderen, einfacheren Fall, in dem sich die Beteiligten alle bereits kennen und sich durch persnlich zugestellte ffentliche Schlssel ihre PKI aufbauen. Dies nennt man eine unmittelbare Vertrauensbeziehung (Direct Trust). In diesem Fall knnen die ffentlichen Schlssel direkt, zum Beispiel per Diskette oder ber ein anderes sicheres Medium ausgetauscht werden. In jedem Fall muss die Vertrauensbeziehung aller Beteiligten untereinander aber schon vor dem Austausch der ffentlichen Schlssel und der darauf basierenden elektronischen Transaktion bestehen. Dies funktioniert noch gut in einer kleinen geschlossenen Gruppe, aber in greren, dezentralen Organisationen tauchen schon grere Probleme auf. In offenen Umgebungen jedoch funktioniert dies berhaupt nicht, da sich die Beteiligten vor der elektronischen Transaktion berhaupt nicht kennen bzw. in keiner Beziehung zueinander stehen. Indirekte Vertrauensbeziehungen Also muss auf eine andere Weise einer Person verbindlich ihr ffentlicher Schlssel zugeordnet und dieser verteilt werden. Ein direkter, elektronischer Austausch ist jedoch nicht sicher, da hier Man-in-the-Middle-Angriffe mglich sind. Die Lsung ist eine zentrale Stelle, bei der die betroffenen Personen vorstellig werden oder auf eine andere, sichere Art ihre Identitt nachweisen und dort ihren ffentlichen Schlssel hinterlegen. Diese zentrale Organisation, die Certificate Authority, stellt der betreffenden Person oder auch Organisation anschlieend ein so genanntes digitales Zertifikat aus, in dem unter anderem der eindeutige Name der Person oder Organisation und deren ffentlicher Schlssel gespeichert ist. Dieses Zertifikat wird abschlieend mit dem privaten Schlssel der Certificate Authority signiert, ist somit von niemandem mehr nderbar und stammt eindeutig von der ausstellenden CA.
162
Die gewnschte gegenseitige Vertrauensstellung erreicht man dadurch, dass alle Beteiligten der CA trauen und damit alle auch einem von dieser CA ausgestellten Zertifikat trauen. In diesem Zertifikat (vgl. Abbildung 5.4) steht neben anderen Informationen zur Lebensdauer und den verwendeten Algorithmen und Schlssellngen der eindeutiger Name seines Besitzers und sein ffentlicher Schlssel. Wie funktioniert nun eine digitale Signatur in der Praxis? In Abbildung 5.3 haben Sie ein Beispiel gesehen, in dem ein Dokument signiert wird. Als Vorbedingung wurde hierbei angenommen, dass sowohl der Sender als auch der Empfnger Mitglieder der gleichen PKI und im Besitz des ffentlichen Schlssels der Certificate Authority sind. Als Signatur-Algorithmus wird RSA, zusammen mit MD5 als Hashverfahren, verwendet. Das digital zu signierende Dokument wird vom Absender mit dessen privatem Schlssel signiert. Da dies bei groen Dokumenten sehr langwierig ist, wird nicht das Dokument selbst, sondern nur sein Hashwert mit dem im Zertifikat spezifizierten Public-Key-Algorithmus verschlsselt. Der Sender schickt sein Zertifikat zusammen mit dem Dokument und seiner Signatur zum Empfnger, damit dieser seinen ffentlichen Schlssel hat. Zuerst muss das Zertifikat des Senders auf Echtheit und Gltigkeit geprft werden. Dies geschieht mit dem ffentlichen Schlssel der CA. Die CA hat das Zertifikat des Senders zum Zeitpunkt seiner Ausstellung mit ihrem privaten Schlssel signiert, indem sie ber das Zertifikat einen Hashwert gebildet und diesen mit RSA verschlsselt hat. Der Empfnger bildet ber das Zertifikat ebenfalls einen Hashwert, entschlsselt die Signatur auf dem Zertifikat mit dem ffentlichen Schlssel der CA und vergleicht beide Werte. Sind sie gleich, wurde das Zertifikat von der CA ausgestellt und nicht verndert. Nun kann aufgrund der Zeitangaben im Gltigkeitsfeld des Zertifikats berprft werden, ob es gltig ist und ob anhand bestimmter anderer Attribut-Eintrge im Zertifikat bestimmte Einschrnkungen fr dessen Besitzer gelten. Wenn alles in Ordnung ist, kann der Empfnger die digitale Signatur mit dem ffentlichen Schlssel, der im Zertifikat des Absenders eingetragen ist, dechiffrieren und erhlt als Ergebnis den Hashwert, den der Absender ber das Dokument gebildet hat. Anschlieend berechnet der Empfnger ber das erhaltene Dokument ebenfalls einen Hashwert und vergleicht dann beide Werte. Sind sie gleich, wei der Empfnger, dass das Dokument nicht verndert wurde und dass es mit dem ffentlichen Schlssel der Person oder Organisation verschlsselt wurde, deren Name im Zertifikat steht. Somit ist das Dokument authentisch und integer. Das Zertifikat des Absenders wird meist mit dem Dokument zusammen zum Empfnger geschickt, da dieser in der Regel nicht die Zertifikate aller mglichen Absender vorliegen hat. Falls der Empfnger den ffentlichen Schlssel oder das Zertifikat des Senders bereits auf eine andere Weise erhalten hat, braucht der Sender sein Zertifikat nicht mitzuschicken.
163
5 Authentifizierung
Falls man eine digitale Signatur ausschlielich zum Authentifizieren benutzt, wird natrlich kein Dokument bertragen und signiert. In diesem Fall signiert die Gegenstelle meist irgendwelche nicht vorherbestimmbare Zufallszahlen und schickt diese zusammen mit der Signatur und ihrem Zertifikat zum Authentifikator. Dieses Verfahren wird Ihnen im Kapitel ber das IKEProtokoll (Kapitel 8) wieder begegnen.
5.4.2
Die Certificate Authority (CA)
Eine Certificate Authority kann eine private oder ffentliche Institution sein oder auch eine Organisationseinheit innerhalb eines Unternehmens. Sie ist fr die Ausstellung, Verteilung, Erneuerung und Sperrung von digitalen Zertifikaten verantwortlich. Da die CA fr die Bindung eines ffentlichen Schlssels an die Identitt einer Person oder Organisation verantwortlich ist, muss diese Identitt auch sorgfltig geprft werden. blicherweise werden davon abhngig auch verschiedene Stufen digitaler Zertifikate ausgestellt. Die hchste Stufe ist in der Regel die, die ein persnliches Erscheinen und den Nachweis der Identitt durch einen Personalausweis erforderlich macht, whrend niedrige Stufen beispielsweise oftmals nur eine gltige E-Mail-Adresse erfordern. In offenen Umgebungen wie dem Internet sind fr elektronische Transaktionen so genannte Serverzertifikate blich. Hier werden vertrauliche Daten, z.B. Kreditkarteninformationen und hnliches, bertragen, die vor unbefugtem Zugriff geschtzt sein mssen. Das Serverzertifikat identifiziert den Server, zu dem die Verbindung aufgenommen wurde.
5.4.3
Die Registration Authority (RA)
Die Registration Authority (RA) fungiert als Annahmestelle fr Antrge zur Erteilung von digitalen Zertifikaten. Ihre Hauptfunktion besteht in der zuverlssigen Identifizierung eines Antragstellers. Im Unternehmensbereich obliegt diese Funktion meist den Personalabteilungen; ffentliche RAs haben entweder eigene Annahmestellen oder benutzen Dienstleistungen anderer Organisationen, die eine entsprechende Infrastruktur betreiben zum Beispiel die Deutsche Bundespost. Ein Antragssteller fr ein rechtsgltiges Zertifikat muss gegenber der RA seine Identitt durch persnliche Anwesenheit und Ausweisdokumente nachweisen.
5.4.4
Zertifikat-Management
Ein zentrale Funktion in einer PKI ist das Management von Zertifikaten und ffentlichen Schlsseln. Zertifikate mssen signiert werden, erneuert werden, verteilt werden und gegebenenfalls vor ihrem natrlichen Ablauf gesperrt
164
werden. Diese Funktion wird, je nach Gre der PKI, von einem oder mehreren Systemen wahrgenommen, die dafr meist verbreitete relationale Datenbanken und Verzeichnisdienste benutzen. Lebensdauer eines Zertifikats Die Lebensdauer eines Zertifikats ist ein wichtiger Faktor, der insbesondere bei Zertifikaten, die natrlichen Personen ausgestellt werden, einen entscheidenden Einfluss auf die Sicherheit und den damit verbundenen Aufwand hat. Zertifikate, die eine sehr kurze Lebensdauer haben, mssen sehr oft verlngert oder erneuert werden. Dies hat je nach Gre der PKI einen erheblichen Administrationsaufwand zur Folge. Andererseits stellen Zertifikate, die sehr lange gltig sind, fr viele Sicherheitsverantwortliche ein Sicherheitsrisiko dar. Dies hngt damit zusammen, dass die Zertifikate in vielen Umgebungen auch dazu benutzt werden, bestimmte Rechte oder Einschrnkungen mit einer Person zu verbinden. Je nach Ttigkeit und Vertrauenswrdigkeit der Person kann sich dies natrlich laufend ndern. Falls hier nicht organisatorisch dafr gesorgt wird, dass diese nderungen Eingang in das Zertifikat der betreffenden Person finden, dann knnen hier tatschlich Sicherheitslcher entstehen. Eine kurze Gltigkeit des Zertifikats wrde dieses Problem entschrfen, denn ein erneuertes Zertifikat wrde immer die aktuellen Rechte und Einschrnkungen des Betreffenden enthalten. Zertifikate, die beispielsweise fr Security-Gateways ausgestellt werden, haben meist eine lange Gltigkeitsperiode, da sich ihr Sicherheitsstatus und ihre Funktionalitt nicht so oft ndern, wie dies bei einer Person der Fall ist. Protokolle zur Anforderung und Verteilung von Zertifikaten Es gibt eine Reihe meist herstellerspezifischer Verfahren und Protokolle zur Verteilung von Zertifikaten. Dabei muss man zwischen der Anforderung eines Zertifikats (Certificate Request) und der Zustellung des von der Certificate Authority signierten Zertifikats unterscheiden. Viele Hersteller haben zu diesem Zweck eigene Verfahren entwickelt, aber aufgrund der zunehmenden Bedeutung der digitalen Signatur zur Benutzer-Authentifizierung hat die Internet Engineering Task Force (IETF) eine entsprechende Arbeitsgruppe gegrndet, die an den ntigen Standards arbeitet und schon ziemliche Fortschritte gemacht hat. Sperrlisten Beim Lesen dieses Abschnitts werden Sie sich vielleicht gefragt haben, was passiert, wenn beispielsweise ein Zertifikat mit einer Gltigkeitsdauer von drei Monaten ausgestellt wurde, dessen Besitzer aber aus unschnen Grn-
165
5 Authentifizierung
den von seinem Unternehmen vor dem Ablaufdatum des Zertifikats entlassen wurde. Dann knnte sich der Betreffende mit diesem Zertifikat weiterhin auf den Systemen seines Unternehmens authentifizieren. Das ist in der Tat so. Um dieses Problem auf ein ertrgliches Ma zu reduzieren, verwendet man so genannte Zertifikat-Sperrlisten (CRL, Certificate Revocation List), in denen die Seriennummern von Zertifikaten enthalten sind, die zwar aufgrund ihrer Zeiteintrge noch gltig sind, aber von der Certificate Authority fr ungltig erklrt wurden. Diese Liste wird an die Systeme verteilt, die sie bentigen. Je nach Durchdringung der PKI mit entsprechenden Applikationen, die ffentliche Schlssel benutzen, knnen dies alle beteiligten Systeme sein. In anderen Fllen, in denen Signaturen nur zur Authentifizierung benutzt werden, mssen nur die beteiligten Zugangskontrollsysteme die Sperrlisten erhalten. Allerdings sind die Sperrlisten selten sehr zeitnah, denn die Verteilung erfolgt meist in bestimmten Intervallen.
5.4.5
Die Qual der Wahl: ffentliche oder private Zertifikate
Ich mchte im Zusammenhang mit unserem Thema, den virtuellen privaten Netzen, nicht zu sehr auf dieses fr viele Unternehmen neue und gleichzeitig kritische Thema eingehen. Denn kein Unternehmen wird auf die Idee kommen, ausschlielich zur Benutzer-Authentifizierung eine PKI in seinem VPN einzufhren. Aber eine PKI und deren Zertifikate zur Authentifizierung zu benutzen, wenn sie bereits vorhanden sind oder im Aufbau ist, das ist eine andere Sache. Ebenso zeugt es auch von Weitsichtigkeit, das Thema digitale Signatur zu bercksichtigen, auch wenn noch keine aktuellen Projekte anstehen oder in Planung sind. Obwohl das Thema PKI in erster Linie kein Netzwerkthema ist, spielt es im Bereich der Benutzer-Authentifizierung eine zunehmend wichtige Rolle. Die Frage, ob man in seinem Unternehmen eine eigene, private PKI betreibt oder eine ffentliche verwendet, hngt von einer ganzen Reihe sicherheitstechnischer, unternehmerischer und gesetzlicher Rahmenbedingungen ab. Der wesentliche Unterschied liegt in der Kompatibilitt mit Zertifikaten anderer PKIs in anderen Unternehmen und in rechtlichen Fragen. Die Kostenfrage spielt natrlich auch eine Rolle: Insbesondere bei kleineren Unternehmen ist es in der Regel nicht wirtschaftlich, eine eigene PKI mit der ntigen Hard- und Software und dem geeigneten Personal zu betreiben. Rechtlich gltige Zertifikate sind generell bei einer externen Certificate Authority zu beantragen. Hier bleibt keine andere Wahl, denn diese Zertifikate bedingen ein von den zustndigen Aufsichtsbehrden zugelassenes Trust-Center, das bestimmte Auflagen erfllen muss. In Deutschland wird all dies vom Signaturgesetz SigG, im Artikel 3 des Gesetzes zur Regelung von Rahmenbe-
166
dingungen fr Informations- und Kommunikationsdienste, dem IuKDG (Informations- und Kommunikationsdienste-Gesetz) vom 22.7.1997 und in der daraus abgeleiteten Signaturverordnung SigV vom 8.10.1997 geregelt.
5.4.6
Das Signaturgesetz und die EU-Richtlinie
Man darf sich von dem Ausdruck mit dem Signaturgesetz konform nicht dahin gehend in die Irre leiten lassen, ein mit einer solchen Signatur elektronisch unterschriebenes Dokument wre rechtlich der Schriftform gleichzusetzen das ist nicht der Fall. Eine Qualifizierung als Privaturkunde gem 416 ZPO (Zivilprozessordnung) kommt bei einem digital signierten elektronischen Dokument auch nicht in Betracht, denn im SigG fehlt jede gesetzliche Bezugnahme. Leider ist die Rechtsunsicherheit gegenber Dokumenten in Schriftform auch nicht in dem Mae geschrumpft, wie es sich viele Anwender gewnscht haben mgen. Einzig die Authentizitt des Absenders einer Nachricht und die Integritt der darin bertragenen Daten gelten als so genannte gesetzliche Vermutungswirkungen. Was aber gilt, ist, dass jemand, der eine andere als die digitale Signatur nach dem SigG einsetzt, im Rahmen eines mglichen Prozesses einen rechtlichen Nachteil erleiden kann. Es gibt in Deutschland mittlerweile einige private Unternehmen, die alle rechtlichen und technischen Voraussetzungen erfllen, um als ffentliche Trust-Center gesetzeskonforme digitale Zertifikate auszustellen. Allerdings mssen die Trust-Center, die solche Signaturen erzeugen, extreme Sicherheitsauflagen erfllen und in regelrechten Hochsicherheitsbunkern ihrer Ttigkeit nachgehen. Sogar die Tren mssen dort nicht nur aus dickem Stahl hergestellt sein, sondern auch eine Zertifizierung haben. Das fhrt natrlich dazu, dass gesetzeskonforme Zertifikate recht teuer werden. Kritiker sprechen von einer berregulierung, die obendrein noch voll am Markt und den Bedrfnissen der Anwender vorbei zielt. Denn bisher kann man nur von einem Flop reden: Statt der Millionen erwarteter Zertifikate haben die Firmen nur wenige tausend vertreiben knnen. Die Finanzwelt benutzt eigene Standards und interessiert sich bislang nicht sonderlich fr gesetzeskonforme Signaturzertifikate. Viele Unternehmen setzen eigene PKIs ein oder benutzen ffentliche, nicht zertifizierte und dadurch viel billigere Trust-Center. Viele dieser nicht SigG-konformen Trust-Center bieten verschieden starke Zertifikate an: normale, die man sich per gltiger (und berprfter) E-MailAdresse erteilen lassen kann, und andere, starke Zertifikate, die eine persnliche Anwesenheit mit gltigen Ausweispapieren bei einer RA erfordern. Somit knnen Kunden auswhlen, welche Sicherheitsstufen sie bentigen, und fr das bentigte Ma an Sicherheit bezahlen. Viele andere Staaten, beispielsweise auch die USA, setzen statt auf staatliche berregulierung auf eine Selbstregulierung durch den Markt eine Idee, die der Europischen Union (EU) mittlerweile auch gekommen ist.
167
5 Authentifizierung
So werden in der EU-Richtlinie zur digitalen Signatur (Richtlinie 1999/93/EG des Europischen Parlaments und des Rates vom 13. Dezember 1999 ber gemeinschaftliche Rahmenbedingungen fr elektronische Signaturen), die am 19. Januar 2000 in Kraft getreten ist, gnzlich andere Tne angeschlagen als im zum Zeitpunkt der Entstehung dieses Kapitels noch gltigen deutschen Signaturgesetz. Es werden darin zwei verschieden starke Arten von Signaturen, die elektronische Signatur und die fortgeschrittene elektronische Signatur, festgeschrieben, die auch eine unterschiedliche rechtliche Bedeutung erlangen. So unterscheidet diese Richtlinie im Artikel 2 (Begriffsbestimmungen) zwischen: 1. Elektronische Signatur: Daten in elektronischer Form, die anderen elektronischen Daten beigefgt oder logisch mit ihnen verknpft sind und die zur Authentifizierung dienen. 2. Fortgeschrittene elektronische Signatur: eine elektronische Signatur, die folgende Anforderungen erfllt: Sie ist ausschlielich dem Unterzeichner zugeordnet. Sie ermglicht die Identifizierung des Unterzeichners. Sie wird mit Mitteln erstellt, die der Unterzeichner unter seiner alleinigen Kontrolle halten kann. Sie ist so mit den Daten, auf die sie sich bezieht, verknpft, dass eine nachtrgliche Vernderung der Daten erkannt werden kann. Zusammen mit weiteren Regelungen entspricht damit die fortgeschrittene elektronische Signatur nahezu der im alten deutschen Signatur-Gesetz beschriebenen Signatur. Im Augenblick ist ein Gesetzentwurf des Bundeskabinetts vom 16. August 2000 im Gesetzgebungsverfahren, der voraussichtlich im Frhjahr 2001 in Kraft treten wird. Der Auslser dafr war die oben genannte EU-Richtlinie, deren Umsetzungsfrist am 19. Juli 2001 abluft. Das alte Signatur-Gesetz, so das Bundeskabinett in seiner Begrndung fr den Neuentwurf, soll wegen der erheblichen strukturellen und inhaltlichen nderungen gegenber dem geltenden Signaturgesetz ... durch den vorgelegten Gesetzentwurf insgesamt abgelst werden. Ein weiterer wichtiger Punkt der Richtlinie und deren nationaler Umsetzung ist die Gleichstellung aller in anderen EU-Staaten erteilter und im Sinne der EU-Richtlinie gleichwertiger Zertifikate. Das heit, ein Zertifikat eines Trust-Centers, das aufgrund der gesetzlichen Umsetzung der EU-Richtlinie in einem anderen EU-Mitgliedsstaat akkreditiert ist, ist einem in Deutschland von einem dort akkreditierten Trust-Center erteilten Zertifikat gleichwertig also ist der bisher rein deutsche Wettbewerb gesetzeskonformer Trust-Center untereinander mittlerweile dabei, ein europischer zu werden. Erweiterungen durch Abkommen mit Nicht-EU-Staaten sind ebenfalls geplant bzw. in Vorbereitung.
168
Tunneling-Technologien im berblick
Das Tunneling ist die Basis moderner VPNs. Mit Hilfe dieser Technologie kann man Pakete eines Netzwerkprotokolls in Pakete eines anderen Netzwerkprotokolls kapseln und ber dieses Netzwerk bertragen. Auf diese Weise kann man zum Beispiel IPX-Pakete durch ein IP-Netzwerk transportieren. Eine andere, speziell fr IP-Netze interessante Anwendung ist das Verstecken von privaten, nicht registrierten Netzwerk- und Hostadressen, indem man IP in IP tunnelt. Auf diese Weise kann man seine privaten Netze ber das Internet miteinander verbinden. Man kapselt hierzu die IP-Pakete mit privaten Adressen in Pakete mit offiziell registrierten IP-Adressen ein und transportiert diese durch das Internet zur Gegenstelle, die die originalen Pakete wieder auspackt.
bertragungsstrecke
TunnelEndpunkt TunnelEndpunkt
Tunneling-Protokoll
Daten L-3 L-2 L-1
Encapsulation
Daten L-3 Protocol Header

L-3 L-2 L-1
Decapsulation
Daten L-3 L-2 L-1
Abbildung 6.1: Tunneling ist eine Technologie zum Einkapseln und Transportieren von Netzwerkpaketen in anderen Netzwerkpaketen.
Es gibt eine ganze Reihe von Tunneling-Protokollen, von denen jedoch zwei eine besondere Rolle spielen: das Layer 2 Tunneling Protocol (L2TP) und das IP Security Protocol (IPSec) im Tunnel-Modus. Diese beiden Protokolle sind relativ neu. Sie sind standardisiert, und sie verdrngen zunehmend alle anderen Tunneling-Protokolle in Neuinstallationen. Diesen beiden Protokollen werden aus diesem Grund auch zwei eigene Kapitel (Kapitel 7, IPSec, und Kapitel 9, L2TP) gewidmet. In Abbildung 6.1 sehen Sie einen solchen Vorgang. Die Netzwerkpakete (Layer 3) werden in andere Netzwerkpakete mit einem neuen Layer-3-Header eingekapselt (Encapsulation), und es wird ein Tunnel-Header eingefgt. An diesem Header, der zwischen dem neuen Layer-3-Header und der Nutzlast
169
6 Tunneling-Technologien im berblick
angeordnet sein muss, erkennt der Empfnger, dass es sich um ein Paket des betreffenden Tunneling-Protokolls handelt. Er wertet den Header aus, entpackt das originale Paket (Decapsulation) und transportiert es weiter. Zwischen dem Sender und dem Empfnger, den so genannten Tunnelendpunkten, die durch die Netzwerkadressen des neuen Layer-3-Headers festgelegt sind, besteht eine Tunnelverbindung. In manchen Fllen ist es nicht notwendig, im IP-Protokoll einen speziellen Tunnel-Header einzufgen, denn gem dem Standard benutzt man das Protokollfeld des IP-Headers dazu anzuzeigen, welches Protokoll auf den Header folgt. blicherweise ist dies TCP (mit Protokollnummer 6) oder UDP (mit Protokollnummer 17). Wenn jedoch die Nummer 4 (IP) in diesem Feld enthalten ist, wei die Gegenstelle, dass ein IPPaket folgt, also ein vollstndiges Paket eingekapselt wurde. Auf diese Weise kann man IP-in-IP-Tunneling ohne einen speziellen Header verwenden. Die Tunnelendpunkte knnen in der Regel sowohl normalen Netzwerkverkehr als auch Tunnelpakete verarbeiten. Wie ein Paket zu behandeln ist, erkennt der Empfnger am Tunnel-Header oder an der IP-Protokollnummer. Der Sender nimmt eine Einkapselung aufgrund der Verarbeitungsstrategie einer hheren Protokollschicht vor. Dabei kann es sich um eine Sicherheitsstrategie handeln oder um interne Tabellen mit Kennzeichnungen, aus denen hervorgeht, welche Pakete normal zu transportieren sind und welche getunnelt werden mssen. Es gibt allerdings eine Ausnahme: Security-Gateways werden aus Sicherheitsgrnden manchmal so konfiguriert, dass sie ausschlielich Tunneling-Protokolle terminieren und keine normalen Protokolle wie zum Beispiel SNMP, FTP usw.
6.1
Tunneling-Modelle
In Abhngigkeit davon, wo die Tunnel beginnen und enden, kann man drei verschiedene, so genannte Tunneling-Modelle unterscheiden: das Ende-zuEnde-Modell, das Provider-Enterprise-Modell und das Intra-Provider-Modell. In Abbildung 6.2 sehen Sie die drei Modelle im Vergleich.
6.1.1
Das Intra-Provider-Modell
Das Intra-Provider-Modell zeichnet sich dadurch aus, dass die Tunnel bei den Service Providern beginnen und enden. Gegenber den beiden anderen Modellen hat diese Variante einen entscheidenden Vorteil: Auf der Seite des Kunden muss keine spezielle Hard- oder Software installiert werden, er kann seine vorhandenen Systeme weiter benutzen und ist nicht in das Tunneling involviert. Die notwendigen Gateways werden von den Providern betrieben und stehen normalerweise auch in deren Rumen. Dieses Modell wird vorwiegend fr Remote-Access-VPNs verwendet, kann jedoch auch fr BranchOffice-VPNs eingesetzt werden.
170
Tunneling-Modelle
Das Bay Dial VPN Service Protocol (BayDVS) der Firma Nortel Networks ist ein Vertreter der fr dieses Modell geeigneten Tunneling-Protokolle. Die RemoteAccess-Clients sind Standardprogramme und meist bereits in den Betriebssystemen integriert (Microsoft DF-Netzwerk, Unix PPPD usw.). Das VPNGateway auf der Seite des Service Providers verbindet den Tunnelendpunkt zum Beispiel ber einen Frame-Relay-PVC mit dem Router des Kunden. Der Kunde wei somit, dass aller Verkehr ber diesen PVC durch einen oder mehrere Tunnel zu den POPs (Point of Presence) des Providers gefhrt wird. Er selbst setzt aber keinerlei spezielle Tunneling-Technologie ein.
6.1.2
Das Provider-Enterprise-Modell
Beim Provider-Enterprise-Modell sind sowohl die Service Provider als auch die Endkunden in das Tunneling involviert. Die Tunnel beginnen im POP des Service Providers und enden im Gateway des Kunden. Dieses Modell wird primr fr Remote-Access-VPNs eingesetzt, kann aber auch in Branch-OfficeVPNs Verwendung finden. In diesem Modell muss der Kunde eine spezielle Hard- oder Software als VPN-Gateway einsetzen. Die Clientsoftware kann ein beliebiges Einwhlprogramm (Microsoft DF-Netzwerk usw.) sein, da der Tunnel erst im POP des Providers beginnt.
Client ISDN PSTN POP Gateway
Internet
Kunde
Carrier
Service Provider
Carrier
Kunde
Intra-ProviderModell Provider-EnterpriseModell
Ende-zu-Ende-Modell
Abbildung 6.2: Die drei Tunneling-Modelle im Vergleich
Typische Tunneling-Protokolle fr dieses Modell sind das Layer 2 Tunneling Protocol (L2TP) und Layer 2 Forwarding (L2F). In selteneren Fllen setzt man hierfr auch das Point-to-Point Tunneling Protocol (PPTP) ein.
171
6.1.3
Das Ende-zu-Ende-Modell
Im Ende-zu-Ende-Modell werden die Tunnel ausschlielich vom Kunden aufgebaut. Die Carrier und/oder Service Provider sind dabei gar nicht in das Tunneling involviert. Sie transportieren im Fall von IP-VPNs ausschlielich IP-Pakete. Dass in diesen Paketen andere Pakete eingekapselt sind, knnen sie zwar erkennen (wenn sie das wollen), aber es hat keinen Einfluss auf den Transport der IP-Pakete. blicherweise stehen die Gateways zum Netzwerk eines Providers in den Rumen der Endkunden, sind deren Eigentum und werden auch von ihnen betrieben. Jedoch kann dieses Modell auch als so genannter Carrier Managed Service von einem Service Provider oder Carrier betrieben werden. Die Remote-Access-Clients whlen sich in die POPs der Service Provider ein, und eine spezielle VPN-Clientsoftware im Endgert des Kunden baut daraufhin einen Tunnel zu einem VPN-Gateway im Kundennetzwerk auf. Theoretisch kann man fast alle Tunneling-Protokolle in einem Ende-zu-EndeModell einsetzen, jedoch sind einige Protokolle besser dafr geeignet als andere. Im Ende-zu-Ende-Modell setzt man vorwiegend IPSec im Tunnelmodus und das Point-to-Point Tunneling Protocol (PPTP) ein. In seltenen Fllen verwendet man das Layer 2 Tunneling Protocol (L2TP) mit einer speziellen Clientsoftware in diesem Modell.
6.2
Man kann die Tunneling-Protokolle in zwei verschiedene Klassen einteilen: die Layer-2-Tunneling-Protokolle und die Layer-3-Tunneling-Protokolle. Die Unterscheidung basiert auf der Schicht des OSI- oder IP-Schichten-Modells, deren Pakete eingekapselt werden. Layer-2-Protokolle kapseln Pakete der Sicherungsschicht (Layer 2) in andere Pakete, meist solche der Schicht 3, ein. Layer-3-Protokolle kapseln Pakete der Netzwerkschicht (Layer 3) in andere Pakete der Netzwerkschicht ein.
6.2.1
Layer-2-Tunneling-Protokolle
In Abbildung 6.3 sehen Sie die Funktionsweise des Layer-2-Tunneling. In diesem Beispiel werden PPP-Rahmen (PPP, Point-to-Point Protocol, ein Protokoll, um verschiedene Netzwerkprotokolle ber eine Punkt-zu-Punkt-Verbindung zu transportieren) in IP-Pakete eingekapselt. In den PPP-Rahmen knnen Pakete verschiedener anderer Netzwerkprotokolle wie IP, IPX, VinesIP, NetBEUI usw. enthalten sein. In unserem Beispiel tunnelt das Layer 2 Tunneling Protocol (L2TP) IP und IPX. Beim Tunneling entsteht ein gewisser Overhead, denn auer dem L2TP-Header werden zustzliche UDP-, IP- und
172
PPP-Header erzeugt. Bei groer Nutzdatenlnge fllt dieser Anteil allerdings nicht so sehr ins Gewicht. Der Vorteil von Layer-2-Tunneling-Protokollen ist der, dass eine Vielzahl von Netzwerkprotokollen getunnelt werden kann, ohne dass sich das Tunneling selbst darum kmmern muss, da dies bereits auf der PPP-Ebene erfolgt ist.
Applikation
Applikationspakete TCP
IP
IP
Applikation
SPX
IPX
SPX
IPX
PPP
PPP
L2TPHeader UDP IP Layer-2
Layer-1
ApplikationsPakete TCP
IP
L2TPHeader UDP IP
Layer-2 Layer-1
ApplikationsPakete TCP
IP
SPX
IPX
SPX
IPX
PPP
PPP
bertragungsmedium
Abbildung 6.3: Das Layer-2-Tunneling kapselt Pakete der Schicht 2, hier PPP, ein.
6.2.2
Layer-3-Tunneling-Protokolle
Das Layer-3-Tunneling arbeitet eine Schicht hher als Layer-2-Protokolle. Hier werden Pakete der Netzwerkschicht in andere Pakete dieser Schicht eingekapselt, wie Sie in Abbildung 6.4 sehen. Der Paket-Overhead ist geringer als der von Layer-2-Protokollen. Allerdings muss der Tunneling-Prozess die von den hheren Schichten ankommenden Pakete analysieren und im Tunnel-Header vermerken, welche Art von Protokoll getunnelt wird. In dem Beispiel, das in Abbildung 6.4 zu sehen ist, wird IPSec im Tunnel-Modus eingesetzt. Das gezeigte IPSec-AH-Protokoll (vgl. Kapitel 7) fgt einen IPSec-AHHeader ein. Andere Protokolle, zum Beispiel IPSec-ESP, knnen neben dem Header auch einen Trailer in das zu erzeugende Paket einfgen.
173
Applikation
Applikationspakete TCP IP
Applikation
UDP IP
UDP IP
Applikationspakete TCP IP
UDP
IPSec-AHHeader IP
IPSec-AHHeader IP
UDP
Layer-2 Layer-1
Layer-2 Layer-1
bertragungsmedium
Abbildung 6.4: Das Layer-3-Tunneling kapselt Pakete der Schicht 3, hier IP, ein.
6.2.3
Multi Protocol Label Switching (MPLS)
Im Bereich von Backbone-Netzen setzt sich zunehmend MPLS (Multi Protocol Label Switching) als Tunneling-Protokoll durch, obwohl es streng genommen gar keins ist. In Netzen mit niedriger und mittlerer bertragungsbandbreite und einer berschaubaren Anzahl von Netzen und Vermittlungssystemen ist IP ein ideales Netzwerkprotokoll. In sehr groen Netzen mit zunehmend hheren Geschwindigkeiten bis in den Gbit-Bereich wird die relativ umstndliche Layer-3-Verarbeitung der IP-Pakete jedoch immer mehr zu einem Problem. Beim Routing auf Layer-2-Ebene, zum Beispiel in einem ATM-Netz, hat man diese Performance-Probleme nicht, ist jedoch auf ein bestimmtes Transportmedium festgelegt und damit extrem unflexibel. Man will also die Flexibilitt und Unabhngigkeit der Layer-3-Vermittlung, aber auch die Performance eines Layer-2-Protokolls. Die Lsung liegt eigentlich auf der Hand, man braucht nur eine zustzliche Protokollschicht einzufgen, die zwischen der Ebene 2 und 3 liegt. Diese Ebene stellt die notwendige Entkopplung zwischen den beiden Schichten dar und bildet eine Art virtuelle, topologieunabhngige Schicht 2. In dieser Schicht werden so genannte Label verwendet, aufgrund derer die Weiterleitungsentscheidungen in den MPLS-Routern oder -Switches getroffen werden. MPLS ist nicht die einzige Entwicklung dieser Art. Gegenber herstellereigenen Protokollen wie dem Tag-Switching von Cisco oder ARIS (Aggregate RouteBased IP Switching) von IBM bietet MPLS jedoch den Vorteil der offiziellen Standardisierung durch die Internet Engineering Task Force (IETF), die eine spezielle
174
MPLS-Arbeitsgruppe zu diesem Zweck ins Leben gerufen hat. MPLS ist zwar vllig unabhngig vom Layer-3-Protokoll, jedoch ist aufgrund der Entwicklungen im Netzwerkbereich eine Fokussierung auf das IP-Protokoll erfolgt. MPLS ist genau genommen kein echtes Tunneling-Protokoll, da es keine Kapselung von Paketen im Sinne von Protokollen wie L2TP oder IPSec vornimmt, sondern nur einen zustzlichen Transport-Header zwischen Layer 2 und 3 einfgt. Man bezeichnet MPLS deshalb auch scherzhaft als Layer-2-Protokoll. MPLS ist ein reines Carrier- und Service-Provider-Protokoll und wird blicherweise in deren Backbones eingesetzt. Ein Einsatz in Unternehmensnetzen macht nur in sehr groen Netzwerken Sinn. Jedoch ist eine gewisse Durchdringung in Campusnetze durchaus denkbar, da MPLS nicht nur unabhngig von der Schicht 3, sondern auch von der Topologie, also der Schicht 2, ist. Es kann dadurch auch zum Beispiel in Ethernet-Switches eingesetzt werden. Alle beteiligten Router und WAN-Switches mssen das Protokoll kennen und entsprechend ihrer Rolle verarbeiten knnen. Es gibt, hnlich zum DiffServModell, Router, die an der Grenze des Netzwerks normale IP-Pakete in MPLS-Pakete und zurck transformieren und reine MPLS-Transport-Router. Diese Systeme, deren Anordnung im Netzwerk Sie in Abbildung 6.5 sehen, nennt man Label Edge Router (LER) und Label Switching Router (LSR). MPLSRouter mssen sich wie IP-Router ber die Vergabe der Label austauschen. Dies kann ber ein spezielles Label Distribution Protocol (LDP) oder auch ber das Resource Reservation Protocol (RSVP) geschehen.
LSR LSR
LER
LER
LSR
LSR
LSR
LSR
LSR
Applikationspaket
Applikationspaket TCP
UDP
IP (Layer-3) Layer-2 Layer-1
TCP
UDP
IP (Layer-3)
Applikationspaket TCP
UDP
IP (Layer-3) Layer-2 Layer-1
Label
Layer-2 Layer-1
Abbildung 6.5: MPLS fgt zum Pakettransport durch ein MPLS-Netz temporr eine neue Schicht (Label) zwischen Layer 2 und 3 ein.
Ein groer Vorteil von MPLS ist der, dass es keine Hardwaremodifikationen voraussetzt.
175
6.3
Es gibt eine ganze Reihe verschiedener Tunneling-Protokolle, aber nur ganz wenige davon wurden von einem Standardisierungsgremium auch als verbindlicher Standard verabschiedet. Die fr IP-VPNs interessanten und zukunftssicheren Protokolle sind das IP Security Protocol (IPSec) und das Layer 2 Tunneling Protocol (L2TP). GRE (Generic Routing Encapsulation) spielt als allein stehendes TunnelingProtokoll keine groe Rolle, dient aber als Grundlage fr andere nicht standardisierte Protokolle, wie zum Beispiel fr das Point-to-Point Tunneling Protocol (PPTP) oder Bay-DVS. Aus diesem Grund wird in diesem Buch auch nicht explizit auf GRE eingegangen.
6.3.1
IP Security Protocol (IPSec) im Tunnel-Modus
IPSec im Tunnel-Modus dient meist als Basis fr das Ende-zu-Ende-Modell. Alle beteiligten Systeme mssen mit einer entsprechenden IPSec-Implementierung ausgerstet sein. In Abbildung 6.6 sehen Sie am Beispiel eines Remote-Access-VPNs die Funktionsweise. Die IPSec-Tunnel beginnen und enden auf dem Endsystem des Kunden, meist einem Rechner mit IPSecClientsoftware und einem IPSec-Gateway. Die Carrier und Service Provider sind nicht am Tunneling beteiligt und transportieren aus ihrer Sicht nur die IP-Pakete zwischen Client und Gateway. Das ffentliche Interface des IPSecGateways hat eine feste, offiziell registrierte IP-Adresse. Auch der Client bekommt bei der Einwahl in den POP eines Service Providers eine offizielle IP-Adresse zugewiesen. Das private Interface des Gateways kann in einem nicht registrierten IP-Netzwerk liegen.
IPSecClient ISDN PSTN POP IPSecGateway
Internet
Kunde
Carrier
Service Provider
Carrier
Kunde
IPSec-Tunnel
IPSec Daten IP IPSec IP L-2 L-1
Abbildung 6.6: IPSec im Tunnel-Modus
176
Beim Client ist die Sache ein klein wenig komplexer. Er hat auch zwei IPAdressen: zum einen die ihm vom Provider fr die DF-Verbindung (DF, Datenfernbertragung) zugewiesene, offizielle, und zum anderen seine private IP-Adresse aus dem Adressbereich des Kundennetzes. Einige IPSec-Implementierungen erfordern leider, dass der Client immer die gleiche offizielle IP-Adresse zugewiesen bekommt, wodurch diese damit faktisch zu einer statischen Adresse wird. Das ist den Internet Service Providern (ISP) ein Greuel, da deren verfgbare Adressen immer mehr zur Neige gehen. blicherweise werden den Einwhl-Clients die IP-Adressen vom den ISPs dynamisch aus einem so genannten IP-Adress-Pool zugewiesen. Diese Pools haben in der Regel so viele Adressen, wie der Provider an gleichzeitigen physikalischen Verbindungen zur Verfgung stellen kann. Da sich aber nie alle Kunden eines ISPs gleichzeitig einwhlen, haben die Provider ihre POPs in der Regel berbucht, sie haben also mehr Kunden als Einwhlports und damit auch weitaus weniger IP-Adressen als Kunden. Falls nun pro Client eine feste IPAdresse reserviert werden msste, wren die Provider gezwungen, eine viel grere Anzahl von Adressen vorzuhalten, als wirklich zum Betrieb bentigt werden und das wird langsam zu einem Problem, da die Adressen fr IP Version 4 weltweit immer knapper werden. Manche Provider struben sich daher gegen statische IP-Adressen fr Remote-Access-Clients, oder sie verlangen entsprechende Gebhren, was dem eigentlichen Zweck eines VPN Kosten zu senken widersprche. Also sollte bei der Auswahl der IPSec-Client-Implementierung darauf geachtet werden, dass diese eine dynamische Zuweisung der offiziellen IP-Adressen untersttzt. Die private IP-Adresse kann bei guten Client-Implementierungen auch dynamisch durch den Tunnel vom Gateway zugewiesen werden. Hier ist vom IPSec-Standard kein Verfahren festgeschrieben, es existieren lediglich standardisierte Funktionen, um herstellerspezifische Erweiterungen einzubinden. Manche Implementierungen, zum Beispiel FreeS/WAN in Linux, untersttzen leider nur eine manuelle, statische Konfiguration der privaten Client-IPAdresse. IPSec ist primr ein Sicherheitsprotokoll auf IP-Ebene; IP-Tunneling ist eine mgliche Option die allerdings in VPNs fast immer eingesetzt wird. Die Sicherheitsfunktionen von IPSec sind in Kapitel 7 ausfhrlich beschrieben. Die Einkapselung der privaten IP-Pakete IPSec kann nur IP-Pakete tunneln erfolgt je nach Sicherheitsstufe durch einen IPSec-Header oder einen IPSecHeader und -Trailer. Ein Protokollfeld in den IPSec-Headern gibt an, welches Protokoll im IPSec-Paket eingekapselt ist. Dies sind im Tunnel-Modus ausschlielich IP-Pakete oder, falls es sich um den IPSec-Transport-Modus handelt, Pakete der Transportschicht (Layer 4), z.B. UDP oder TCP.
177
6.3.2
Layer 2 Tunneling Protocol (L2TP)
Das Layer 2 Tunneling Protocol wurde primr fr den Einsatz im ProviderEnterprise-Modell entwickelt. Wie Sie in Abbildung 6.7 sehen, beginnt dabei der L2TP-Tunnel im Remote Access Concentrator (RAC) des Service Providers und endet in einem Gateway beim Kunden. Die Funktionalitt der Tunnelendpunkte ist rollenbasierend, der Tunnel wird von einem LAC (L2TP Access Concentrator) aufgebaut, der im RAC des Providers implementiert ist. Das entgegengesetzte Ende des Tunnels bildet der LNS, der L2TP Network Server, der entweder auf Routern oder auf speziellen VPN-Gateways implementiert ist.
Client ISDN PSTN L2TPLAC (RAC) L2TPLNS
Internet
Kunde
Carrier
Service Provider
Carrier
Kunde
PPP
L2TP-Tunnel
Daten IP PPP L-1
Daten IP PPP L2TP UDP IP L-2 L-1
Abbildung 6.7: L2TP im Provider-Enterprise-Modell
Der RAC des Service Providers erkennt an bestimmten Kennzeichen eines eingehenden Rufs (angerufene Nummer, Benutzer-ID usw.), ob es sich um eine Verbindung in das Netzwerk des Providers handelt oder ob die Verbindung zu einem Endkunden getunnelt werden soll. Dieses Verhalten nennt man auch zwangsweises Tunneling (Compulsory Tunneling), da der Client nicht selbst entscheiden kann, ob ein Tunnel aufgebaut wird oder nicht. Im ProviderEnterprise-Modell muss das Equipment beim Kunden eine L2TP-LNS-Funktionalitt bieten. Das betreffende System muss aber nicht notwendigerweise dem Kunden gehren und muss auch nicht von ihm verwaltet werden oft bieten die Service Provider komplette Lsungen an, inklusive VPN-Systemen, Konfiguration, Wartung und Betrieb. Leider sind in L2TP keinerlei Sicherheitsfunktionen wie Datenverschlsselung oder Authentifizierung verfgbar.
178
L2TPLAC ISDN PSTN
POP
L2TPLNS
Internet
Kunde
Carrier
Service Provider
Carrier
Kunde
L2TP-Tunnel
Daten IP PPP L2TP UDP IP L-2 L-1
Abbildung 6.8: L2TP im Ende-zu-Ende-Modell
L2TP kann auch im Ende-zu-Ende-Modell eingesetzt werden. Zu diesem Zweck wird die LAC-Funktionalitt vom Remote-Access-Konzentrator des Service Providers auf den Client verlagert. Dieser so genannte Virtual LAC auf dem Clientrechner baut den L2TP-Tunnel zum LNS auf, und die Carrier und Service Provider sind nicht mehr in das Tunneling involviert. Im Gegensatz zum zwangsweisen Tunneln, nennt man dies freiwilliges Tunneln (Voluntary Tunneling). Ein Beispiel fr eine solche Funktionalitt finden Sie bei Windows 2000 Professional, das als VPN-Protokoll auch L2TP als virtuellen LAC implementiert hat. Das Layer 2 Tunneling Protocol ist aufgrund seiner wachsenden Bedeutung in Kapitel 9 ausfhrlich beschrieben.
6.4
Neben den standardisierten Tunneling-Protokollen gibt es eine ganze Reihe anderer Protokolle, die jedoch niemals in Form eines verbindlichen Standards das Licht der Welt erblickt haben. Manche dieser Protokolle wurden zwar in Standardisierungsprozesse eingebracht, haben diese aber niemals vollstndig durchlaufen oder existieren nur als informeller Standard. Das Point-to-Point Tunneling Protocol (PPTP) oder Layer 2 Forwarding (L2F) sind Beispiele hierfr. Andere Protokolle sind proprietr und werden nur innerhalb der Produktlinien bestimmter Hersteller verwendet, wie zum Beispiel der Altavista Tunnel, der Bay Dial VPN Service (Bay-DVS) oder das Ascend Tunnel Management Protocol (ATMP). Manche dieser proprietren Protokolle schmcken sich zwar mit
179
RFC-Nummern, allerdings sind diese nur informeller Natur und reprsentieren keinen verbindlichen Internetstandard.
6.4.1
Layer 2 Forwarding (L2F)
Das Layer 2 Forwarding ist ein Layer-2-Tunneling-Protokoll, das hauptschlich von der Firma Cisco zum Einsatz im Provider-Enterprise-Modell entwickelt wurde. Es gibt praktisch keine Client-Implementierungen, sondern nur Softwaremodule fr Remote-Access-Konzentratoren und Router. L2F ist sehr eng mit L2TP verwandt, viele L2TP-Network-Server knnen auch als Endpunkt fr einen L2F-Tunnel dienen. L2F bietet keine Sicherheitsdienste wie Datenverschlsselung oder starke Authentifizierung, kann aber, wie auch L2TP und PPTP, verschiedene Netzwerkprotokolle tunneln.
6.4.2
Point-to-Point Tunneling Protocol (PPTP)
Das Point-to-Point Tunneling Protocol wurde von einer Reihe von Firmen entwickelt, die zu diesem Zweck das so genannte PPTP-Forum grndeten. Der Software-Riese Microsoft war, neben Unternehmen wie Ascend Communications, 3Com und anderen, mageblich an der Entwicklung beteiligt und hat seine PPTP-Clientsoftware in alle seine Betriebssysteme integriert bzw. fr ltere Systeme wie Windows 95 Updates (Microsoft Dialup Networking Update 1.3) auf den Markt gebracht. PPTP kann sowohl als Basis fr das Ende-zu-Ende-Modell dienen als auch durch Implementierungen in RemoteAccess-Konzentratoren im Provider-Enterprise-Modell eingesetzt werden. PPTP hat einen dem L2TP hnlichen Aufbau. Fr den Steuerungskanal verwendet PPTP jedoch das TCP-Protokoll. Als Layer-2-Protokoll kapselt PPTP PPP-Rahmen mit einem modifizierten GRE-Header ein. PPTP bietet auch einige Sicherheitsfunktionen wie Datenverschlsselung (MPPE, Microsoft Point-to-Point Encryption) und Benutzer-Authentifizierung, die allerdings bei weitem nicht die Strke von IPSec aufweisen. Insbesondere die Ableitung des Schlssels, mit dem die Daten verschlsselt werden, aus der Benutzer-Authentifizierung war in der Vergangenheit Zielscheibe einiger erfolgreicher Angriffe. Der Schlssel des eingesetzten RC4-Protokolls ist zwar, je nach der Version von PPTP, entweder 40 oder 128 Bit lang aber er wird aus einem Hashwert des Benutzer-Passworts erzeugt. Also muss ein Brute-Force-Angriff (vgl. Kapitel 4) nicht alle 240 oder 2128 mglichen Schlssel testen, sondern braucht praktisch nur einen Wrterbuchangriff auf das Benutzer-Passwort durchzufhren. Microsoft hat mit einem Update auf die erfolgreichen Angriffe reagiert und eine neue, sicherere Authentifizierung namens MS-CHAPv2 implementiert. Aus Kompatibilittsgrnden kann das neue Verfahren beim Verbindungsaufbau jedoch durch die alte Version ersetzt werden, was eine nicht unbetrchtliche Angriffsflche bietet. In jedem Fall basiert die
180
Verschachtelte Tunneling-Protokolle
Sicherheit der Verschlsselung in PPTP auf der Sicherheit des Benutzer-Passworts und das ist vielen Anwendern ein zu hohes Sicherheitsrisiko. Viele gute Sicherheitsstrategien legen darber hinaus auch gewisse Verfahren und Richtlinien zur Schlsselerzeugung und -Verwaltung fest, so dass der Einsatz von PPTP oft schon an dieser Hrde scheitert. Auch Microsoft verabschiedet sich langsam von seinem Problemprotokoll PPTP. Im neuen Windows 2000 werden verschiedene Tunneling-Protokolle nach wie vor auch noch PPTP angeboten, jedoch wird fr neue Installationen die modernere und sicherere Variante L2TP/IPSec (siehe Kapitel 9) empfohlen. In Provider-Enterprise-Modellen setzen die Service Provider zunehmend auf L2TP, so dass auch hier PPTP immer weiter verdrngt wird.
6.5
Verschachtelte Tunneling-Protokolle
Manchmal bietet ein Tunneling-Protokoll allein nicht alle Funktionen, auf die man groen Wert legt. Die in diesem Kapitel besprochenen Layer-2-TunnelingProtokolle knnen verschiedene Netzwerkprotokolle wie IP, IPX usw. tunneln, zeichnen sich aber nicht gerade durch gute Sicherheitsfunktionen aus. IPSec auf der anderen Seite hat hervorragende Sicherheitsfunktionen, kann aber nur IP tunneln. Was liegt also nher, als zwei verschiedene Tunneling-Protokolle miteinander zu kombinieren. Das kann man auch tun, indem man Tunnel ineinander verschachtelt. Wie dies prinzipiell funktioniert, sehen Sie in Abbildung 6.9. Beim Verschachteln von Tunneln ist es wichtig, dass sich die Tunnel, wie Sie in der Abbildung sehen, nicht berlappen die Tunnel mssen vollstndig ineinander enthalten sein. Man kann grundstzlich sowohl Protokolle gleichen als auch verschiedenen Typs ineinander verschachteln.
bertragungsstrecke Tunneling-Protokoll A Tunneling-Protokoll B
Daten L-3 L-2 L-1
Daten L-3 Header A
Daten L-3 Header A
Daten L-3 Header A
Daten L-3 Header A
Daten L-3 L-2 L-1
L-3 L-2 L-1
L-3 Header B
L-3 L-2 L-1
L-3 Header B
L-3 L-2 L-1
L-3 L-2 L-1
Abbildung 6.9: Tunneling-Protokolle knnen auch ineinander verschachtelt werden.

181
Tunneling-Protokoll A Tunneling-Protokoll B bertragungsstrecke

Abbildung 6.10: Dies geht nicht! Tunneling-Protokolle drfen sich beim Verschachteln nicht berlappen.
Nehmen wir einmal als Beispiel aus der Praxis eine Remote-Access-VPN, um den Sinn und den Einsatz der Verschachtelung von Tunneling-Protokollen zu erlutern. IPSec ist ein Sicherheitsprotokoll, das man gern im Ende-zu-EndeModell einsetzt, um die gewnschte Sicherheitsfunktionalitt mglichst auf der ganzen bertragungsstrecke zwischen Client und VPN-Gateway zur Verfgung zu haben. Dabei gibt es aber mglicherweise ein Problem: Das Endezu-Ende-Modell bedeutet immer, dass der Client freiwillig tunnelt. Ein Benutzer knnte somit aber auf seinem Firmen-PC seinen Dialer manuell starten und sich zum ISP verbinden, ohne seinen IPSec-Client zu benutzen. Das kann unter Umstnden von einer Sicherheitsstrategie verboten sein. Mit dem Provider-Enterprise-Modell, zum Beispiel mit L2TP als TunnelingProtokoll, wre das nicht mglich, denn hier erfolgt ein zwangsweises Tunneling. Der Remote-Access-Konzentrator beim Service Provider kann z.B. aufgrund der angerufenen Nummer (also der Einwahlnummer des ISP, die der Dialer anrufen muss) entscheiden, ob und wohin ein Tunnel aufgebaut werden muss. Der Client kann dies nicht mehr beeinflussen. Allerdings ist L2TP kein Sicherheitsprotokoll. Die Lsung ist eine Verschachtelung von IPSec und L2TP. In Abbildung 6.11 sehen Sie, wie dies realisiert wird: IPSec wird im Ende-zu-Ende-Modell betrieben und garantiert so die geforderte Sicherheit. Mit L2TP im ProviderEnterprise-Modell wird garantiert, dass, sobald sich der Client beim Provider einwhlt, er zwangsweise mit L2TP bis zum LNS im Kundennetzwerk getunnelt wird. Diese Lsung hat allerdings auch ihren Preis in Form eines zustzlichen Protokoll-Overheads in den Datenpaketen. In diesem Zusammenhang fllt auch oft der Begriff L2TP ber IPSec oder IPSec secured L2TP oder kurz L2TP/IPSec. Hierbei handelt es sich nicht um eine Verschachtelung von Tunneling-Protokollen, da IPSec hierbei nicht im Tunnel-, sondern im Transport-Modus arbeitet. Hier hat man die Vielfalt der Protokolle, die L2TP tunneln kann, mit der Sicherheit von IPSec kombiniert. L2TP wird dabei zum Tunneln benutzt, und die erzeugten UDP/IPPakete werden mit IPSec im Transport-Modus verschlsselt und authentifiziert. Diese Kombination ist in Kapitel 9 ausfhrlich beschrieben. Sie wird auch von Windows 2000 untersttzt.
182
Welches Protokoll fr welchen Zweck?
IPSecClient
L2TPLAC ISDN PSTN
L2TPLNS
IPSecGateway
Internet
Kunde
Carrier
Service Provider
Carrier
Kunde
IPSec-Tunnel
L2TP-Tunnel
Daten IP IPSec IP PPP L2TP UDP IP L-2 L-1
Daten IP IPSec IP PPP L-1
Daten IP IPSec IP L-2 L-1
Abbildung 6.11: Eine Kombination von IPSec und L2TP
6.6
Diese Frage ist eigentlich gar nicht so kompliziert, da verschiedene Protokolle fr bestimmte Funktionen von vornherein ausscheiden. Wenn Sie zum Beispiel IPX ber ein IP-Netzwerk transportieren mssen, scheidet IPSec an diesem Punkt bereits aus. Die Gegenberstellung im folgenden Abschnitt soll die Protokolle nicht wertend miteinander vergleichen, denn sie wurden teilweise mit vllig unterschiedlichen Zielsetzungen und Einsatzszenarien entwickelt.
6.6.1
Gegenberstellung
In Tabelle 6.1 sind die vier wichtigsten Tunneling-Protokolle IPSec, L2TP, PPTP und L2F gegenbergestellt. Hier soll aber wie gesagt kein Vergleich im Sinne von gut oder schlecht stattfinden, sondern ein Vergleich der wichtigsten Funktionen der Protokolle. Hier knnen Sie anhand eines Pflichtenhefts oder Anforderungskatalogs schnell ein geeignetes Protokoll finden oder eine Kombination von zwei Protokollen.
183
IPSec Protokolltyp Standardisiert (RFC) Paket-Authentifizierung Benutzer-Authentifizierung Datenverschlsselung Schlsselmanagement QoS-Signalisierung IP-Tunneling IPX-Tunneling Primres Modell Layer 3 Ja Ja Ja Ja Ja Ja Ja Nein Ende-zuEnde
L2TP Layer 2 Ja Nein Ja Nein Nein Nein Ja Ja ProviderEnterprise
PPTP Layer 2 Nein Nein Ja Ja Nein Nein Ja Ja Ende-zuEnde
L2F Layer 2 Nein Nein Ja Nein Nein Nein Ja Ja ProviderEnterprise
Tab. 6.1: Ein Vergleich verbreiteter Tunneling-Protokolle
6.6.2
Auswahlkriterien
Mit der Auswahl eines oder mehrerer Tunneling-Protokolle treffen Sie eine wichtige Entscheidung whrend der Planung des VPNs. In heutigen, modernen Netzwerken ist man bestrebt, mglichst auf Standards oder wenigstens auf De-facto-Standards zu setzen. Aus diesem Grund reduziert sich die Menge der zur Auswahl stehenden Tunneling-Protokolle ganz erheblich: Es bleiben die in Tabelle 6.1 beschriebenen Verfahren, aus denen man ein geeignetes Protokoll auswhlen sollte. Leider gibt es dafr keine allgemeingltige Checkliste oder eine Art VPN-Kochbuch, denn es spielen einfach zu viele unternehmensspezifische Planungs- und Entscheidungskriterien eine Rolle. Die wichtigsten Faktoren sind dabei: Die Netzwerkprotokolle, die bertragen werden mssen Die Sicherheitsstrategie des Unternehmens Die eingesetzten Applikationen Bentigte Client-Untersttzung (Betriebssysteme) Der VPN-Typ Kompatibilittsanforderungen Die Netzwerkprotokolle, die bertragen werden mssen Dieser Faktor ist neben der Sicherheitsstrategie der am meisten ausschlaggebende. Unter Umstnden sollten Sie auch Ihre mittel- und langfristige Netzwerkstrategie zu Rate ziehen, ob nicht vielleicht eine Protokoll-Konsolidie-
184
rung stattfinden soll und nur noch IP brig bleibt. Diese Tendenz ist im Augenblick bei fast allen Unternehmen zu beobachten; bei etlichen ist dieser Prozess auch schon abgeschlossen. Ein VPN ist in diesem Zusammenhang mglicherweise ein guter Punkt, um mit dieser Konsolidierung zu beginnen und nur noch IP zu tunneln. Jetzt werden Sie vielleicht einwenden, dass diese berlegung nichts gebracht hat, denn alle vier Protokolle tunneln IP. Das ist richtig, aber es bleiben mehr Alternativen, um die nachfolgenden Kriterien erfllen zu knnen. Die Sicherheitsstrategie des Unternehmens Die Netzwerkabteilung eines Unternehmens ist in der Regel dafr verantwortlich, die Sicherheitsstrategie des Unternehmens im Netzwerkbereich zu implementieren. Im Fall von Internet-VPNs entstehen dadurch oft ganz bestimmte Anforderungen an die Sicherheitsdienste, die ein geeignetes Tunneling-Protokoll zur Verfgung stellen muss. An diesem Punkt scheiden schon Protokolle wie L2F und L2TP aus, es sei denn, sie werden mit entsprechenden Sicherheitsprotokollen kombiniert. Wenn die Anforderungen an die Sicherheit der Datenbertragung sehr hoch sind, bleibt praktisch keine Alternative zu IPSec. Mssen unbedingt auch andere Netzwerkprotokolle als IP getunnelt werden, kann man L2TP/IPSec verwenden. Die eingesetzten Applikationen Hier ist nicht von Interesse, welche Applikationen benutzt werden, sondern welche Anforderungen an Verzgerungszeiten und Bandbreite sie stellen. Es ist auch von Interesse, ob im privaten Netzwerk bereits Quality-of-ServiceDienste auf IP-Ebene eingesetzt werden und ob diese Informationen an den Service Provider gesendet werden sollen. Hier spielt in gewissem Mae auch schon die Auswahl der VPN-Systeme mit hinein, auf die Kapitel 11 nher eingegangen wird. Bentigte Client-Untersttzung (Betriebssysteme) Wenn, zum Beispiel in einem Remote-Access-VPN, ein Ende-zu-Ende-Modell eingesetzt wird, mssen fr das entsprechende Betriebssystem auch ClientImplementierungen des auszuwhlenden Tunneling-Protokolls existieren. Dies drfte fr L2F schon das Aus sein; hier muss man sich zwischen den restlichen drei Protokollen entscheiden. Der VPN-Typ Natrlich ist es auch wichtig, welcher VPN-Typ zum Einsatz kommt, ob man also ein Remote-Access-, ein Branch-Office- oder ein Extranet-VPN aufbauen will oder beliebige Kombinationen davon. Die Tunneling-Protokolle haben ihre spezifischen Schwerpunkte und sind fr bestimmte Einsatzszenarien
185
nicht geeignet. So bieteten nur ganz wenige Service Provider im Augenblick ein Provider-Enterprise-Modell mit zwangsweisem Tunneling mit IPSec an. Und Branch-Office-VPNs mit L2F fallen auch unter die Rubrik exotisch. Kompatibilittsanforderungen Insbesondere wenn das VPN auch Extranet-Dienste zur Verfgung stellen muss, ist die Kompatibilitt ein ganz wesentliches Entscheidungskriterium. Denn dann muss ein Tunneling-Protokoll eingesetzt werden, das die Organisationen, die angebunden werden sollen, auch benutzen. Natrlich muss nicht notwendigerweise nur ein einziges Tunneling-Protokoll im VPN eingesetzt werden. Falls man aus bestimmten Grnden zum Beispiel sein VPN mit PPTP aufbaut, die externen Extranet-Systeme aber IPSec einsetzen, kann man fr diesen genau abzugrenzenden Bereich auch IPSec einsetzen. Falls die Forderung nach Kompatibilitt jedoch einer grundstzlichen Strategie des Unternehmens entspringt mit dem Ziel, eine mglichst hohe Interoperabilitt und Herstellerunabhngigkeit zu erzielen , sollte man standardisierte Protokolle wie IPSec oder L2TP einsetzen.
186
Das IP-Security-Protokoll (IPSec)
Wenn Sie schon einmal mit einem Protokollanalysator IPSec-Pakete aufgezeichnet und analysiert haben, werden Sie sich mit Sicherheit darber gewundert haben, dass in Ihrem Netz pltzlich IP Version 6 luft, obwohl dieses Protokoll auf keinem einzigen Ihrer Systeme installiert ist. Denn genau das zeigen die Analysatoren in der Regel an, obwohl es sich in Wirklichkeit um normale alte IP-Version-4-Pakete handelt. Um dies zu erklren, muss man um einige Jahre zu dem Zeitpunkt zurckgehen, an dem sich einige Leute daran gemacht hatten, ein neues IP-Protokoll zu spezifizieren, das IPng (IP next generation) oder aufgrund der Protokollnummer IP Version 6 genannt wird. Der Anlass dazu war hauptschlich die Tatsache, dass irgendwann der durch die 4-Byte-Limitierung begrenzte IPAdressraum nicht mehr ausreichen wrde. Auerdem sollte das Protokoll flexibler ausgelegt sein und schon im ursprnglichen Standard Dinge wie Quality-of-Service und Sicherheit untersttzen. Vor allem auch die Header-Struktur der Pakete sollte flexibler ausgelegt werden, um sptere Erweiterungen einfacher in das Protokoll zu implementieren. Leider hat IP in der Version 6, die inkompatibel zur Version 4 ist, bis heute keine nennenswerte Verbreitung gefunden. Die Grnde dafr sind recht vielschichtig: Eine Umstellung bringt bei der heutigen Verbreitung des IP-Protokolls einiges an Aufwand mit sich, beide Protokolle mssen auf vielen Systemen koexistieren, und vor allem gibt es gibt nach wie vor noch IP-Adressen. Denn die ursprngliche Annahme, dass die Adressen schon seit Jahren ausgegangen sein mssten, ging davon aus, dass jedes IP-System auch eine offiziell registrierte und somit weltweit einmalige Addresse zugewiesen bekommt. Aber viele Unternehmen und Organisationen betreiben Netze mit nicht registrierten Adressen und setzen am bergangspunkt zu ffentlichen IP-Netzen Verfahren wie NAT (Network Address Translation) ein, die ihre privaten Adressen dynamisch in offizielle umsetzen. Solche Systeme haben meist einen Satz von einigen hundert offiziellen Addressen (Address-Pools), die auf einige zigtausend private Adressen umgesetzt werden. Vielfach werden auch Rechneradressen nicht mehr statisch vergeben, sondern dynamisch, ebenso wie Internet Service Provider Adressen fr ihre Kunden dynamisch aus Adress-Pools vergeben. Kurzum: Anstatt auf IP Version 6 umzusteigen, hat man bisher auf einen sparsamen Umgang mit IP-Adressen gesetzt. Diese Entwicklung wird zwar demnchst ein Ende haben, wenn durch die Einfhrung von UMTS, IP-Telefonie und einer ganzen Reihe neuer IP-basierender Dienste eine riesige Zahl von IP-Adressen bentigt wird. Sptestens
187
7 Das IP-Security-Protokoll (IPSec)
wenn jeder neue Khlschrank per SNMP gesteuert wird und jedermann ber das IP-Protokoll telefoniert, bentigt man allein wegen des viel greren Adressraums IP Version 6. Allerdings wird bis dahin noch einige Zeit vergehen, und die heutigen sowie die in den nchsten Jahren zu installierenden VPNs werden noch auf dem IP-Protokoll der Version 4 basieren. Aber durch die Verschleppung des neuen IP-Protokolls wurden auch die wichtigen Erweiterungen in IP Version 6 wie Qualtity-of-Service und Sicherheit nicht verfgbar. Also hat sich die IETF daran gemacht, diese Funktionalitten auf IP Version 4 zu portieren. Praktisch alle Funktionen von IPSec stammen aus der Entwicklung von IP Version 6, man hat sogar die Protokollnummern beibehalten und verwirrt dadurch, wie eingangs beschrieben, auch moderne Protokollanalysatoren. Die Standards, die IPSec spezifizieren, beschreiben generell beide IP-Versionen: Alle Parameter wie Protokollnummer, Formate usw. sind gleich, lediglich die Paketformate sind unterschiedlich. In den RFCs werden die Unterschiede zwischen IP Version 4 und Version 6 explizit angesprochen, so dass hier keine Verwechslungen mglich sind.
7.1
IP Security im berblick
IP Security bietet einen weit reichenden Schutz von IP-Datagrammen. Insbesondere werden folgende Bereiche abdeckt: Paketintegritt Paketauthentifizierung Paketvertraulichkeit Verkehrsflussvertraulichkeit Schutz vor Replay-Angriffen Schutz vor weiteren Denial-of-Service-Angriffen
7.1.1
Paketintegritt
IPSec schreibt bestimmte Verfahren vor, mit denen die Paketintegritt, also der Schutz vor unerlaubter Vernderung der Pakete auf dem Transport, gewhrleistet werden kann. Diese Funktionalitt ist ein Muss, es gibt nur eine einzige Ausnahme, bei der diese Funktionalitt nicht durch spezielle Funktionen sichergestellt werden muss, sondern bei der andere Dienste diesen Schutz mit zur Verfgung stellen. Diese Ausnahme liegt bei einer Verschlsselung der Daten vor, denn dann kann eine wirkungsvolle nderung, also ein Angriff, nur erfolgen, wenn der Angreifer den Schlssel kennt, was aber in IPSec praktisch unmglich ist (vgl. Kapitel 8, IKE).
188
IP Security im berblick
Die Paketintegritt wird sichergestellt, indem in das IPSec-Paket ein so genannter Hash-based Message Authentication Code (HMAC) eingefgt wird. Dabei handelt sich um einen krpytographisch durch einen symmetrischen Schlssel abgesicherten Hashwert, der ber das zu versendende IP-Paket gebildet wird. Die korrekte Berechnung des HMAC ist nur dem Sender und dem Empfnger des Pakets mglich, da nur diese ber den notwendigen Schlssel verfgen.
7.1.2
Paketauthentifizierung
Die Paketauthentifizierung, also die Gewhrleistung, dass das Paket auch vom authentischen Absender und niemand anderem kommt, der sich mit geflschten Absenderadressen in die Kommunikation einklinkt, ist praktisch ein Abfallprodukt der Paketintegrittsprfung. Denn diese bildet ihren HMAC unter anderem aus einem symmetrischen Schlssel, der ausschlielich dem Sender und Empfnger, oder genauer formuliert, dem Initiator und Responder der IPSec-Sicherheitsassoziation (SA), bekannt ist. Wenn der Empfnger eines IPSec-Pakets den HMAC berprft und keine nderungen festgestellt hat, dann sind zwei Dinge sichergestellt: Erstens wurde das Paket auf dem Transport nicht verndert, und zweitens kommt das Paket auch definitiv vom anderen Partner der SA, denn auer dem Empfnger selbst kennt nur noch dieser den symmetrischen Schlssel, der zur HMAC-Berechnung bentigt wird.
7.1.3
Paketvertraulichkeit
Die Vertraulichkeit der Daten oder im Falle von IPSec im Tunnelmodus der vollstndigen, privaten IP-Pakete wird durch deren Verschlsselung erreicht. Die Verschlsselung der Daten kann auch benutzt werden, um die Paketintegritt und die Paketauthentizitt in gewissem Mae sicherzustellen. Denn die in IPSec eingesetzten Algorithmen sind symmetrische Verfahren, deren Sicherheit zusammen mit anderen Faktoren darauf basiert, dass der Schlssel nur dem Sender und dem Empfnger bekannt ist. Ein verschlsseltes Paket ndern kann somit auch nur jemand, der den Schlssel ebenfalls kennt, was man durch den Einsatz des IKE-Protokolls zum Erzeugen der notwendigen Schlssel wirkungsvoll verhindern kann.
7.1.4
Verkehrsflussvertraulichkeit
IPSec kann man in zwei verschiedenen Modi betreiben, dem TransportModus und dem Tunnel-Modus. Letzterer kapselt ein privates IP-Paket in den Datenbereich eines neu erzeugten IP-Pakets ein. Sobald dieser Datenbereich verschlsselt wird, kann sich ein Angreifer, der das neue Paket auf dem Transport mitliest, keine Informationen mehr ber Verkehrsbeziehungen im priva-
189
ten Netzwerk verschaffen. Denn das komplette private Paket, inklusive Adressen, Protokollnummern usw. ist verschlsselt. Die einzige Information, die ein Angreifer ermitteln kann, ist die Gesamtmenge an Paketen, die zwischen IPSec-Gateways oder -Hosts verschickt werden.
7.1.5
Schutz vor wiederholtem Senden von Paketen (Replay-Angriff)
Ein Replay-Angriff ist eine Art von Angriff, mit der ein Angreifer trotz Schutzmechanismen wie Integrittsprfung, Authentifizierung und zustzlicher Datenverschlsselung seine Pakete in eine IPSec-Verbindung einschleusen und den Empfnger zu umfangreichen, ressourcenintensiven, aber vllig sinnlosen Berechnungen veranlassen kann. Die Sinnlosigkeit wrde aber erst von der Applikation erkannt, die das private IP-Paket anschlieend weiterverarbeitet. Der Trick des Angreifers besteht einfach darin, dass er IPSecPakete aufzeichnet und diese nochmals zum Empfnger schickt. Dieser verarbeitet das Paket auch ganz normal, denn es ist mit einem korrekten HMAC versehen, lsst sich entschlsseln und sieht von der Sicherheitsseite aus betrachtet normal aus. Wenn nun eine ausreichend groe Anzahl von solchen Pakten wiederholt zum Empfnger geschickt wird, muss er erhebliche Ressourcen fr die kryptographische Verarbeitung aufwenden, die ihm dann fr die Verarbeitung ordnungsgemer Pakete schlielich fehlen. Um sich vor derartigen Angriffen zu schtzen, wurden in IPSec spezielle Manahmen eingefhrt. IP Security berprft hierbei optional durch einen Anti-Replay Service (ARS) jedes eingehende Paket zu allererst daraufhin, ob es schon einmal angekommen ist.
7.1.6
Schutz vor weiteren Denial-of-Service-Angriffen
Es gibt mittlerweile eine Reihe teilweise recht ausgeklgelter Denial-of-Service-Angriffe, also Attacken, die darauf abzielen, ein Gert in einen Zustand zu versetzen, in dem es seine ursprnglichen Aufgaben nicht oder nur noch in unzureichendem Mae ausfhren kann. Solche Angriffe zielen oft auf den TCP-Stack ab oder versuchen, rechenintensive Funktionen in einem System anzustoen. Einen Schutz hiervor kann man erreichen, indem man auf viele Funktionen eines normalen IP-Stacks verzichtet und einen so genannten gehrteten Stack implementiert. Dies ist allerdings nur bei dedizierten VPNGateways mglich, die beispielsweise auf ihrem ffentlichen Interface ausschlielich Tunneling-Protokolle wie IPSec und L2TP terminieren. Ein gehrteter Stack ist so programmiert, dass er nur die Protokolle 50 (IPSec ESP), 51 (IPSec AH) und 17 (UDP) mit den Portnummern 500 in die Schicht 3 durchlsst. Eine TCP-Verarbeitung gibt es auf dieser Ebene nicht, dadurch fallen schon eine ganze Reihe mglicher Angriffe weg. Die IPSec-Protokolle selbst
190
haben bereits eine ganze Reihe eingebauter Schutzmechanismen, ebenso das IKE-Protokoll, das mit UDP-Paketen der Portnummer 500 arbeitet. Alle anderen Pakete werden bereits vor der Ebene 3 ohne weitere Meldung (silent discard) verworfen und knnen keinen weiteren Schaden mehr anrichten.
7.2
Diese ganzen Anforderungen an die Sicherheit der Datenbertragung bedingen, dass eine Reihe von kryptographischen Verfahren eingesetzt wird, flankiert von gewissen Richtlinien zur Implementierung in IPSec, um die verschiedenen mglichen Angriffe abzuwehren.
7.2.1
Datenverschlsselung in IPSec
Die Datenverschlsselung in IPSec wird mit symmetrischen Verfahren (vgl. Kapitel 4) durchgefhrt, die im Cipher-Block-Chaining-Modus (CBC) mit explizitem Initialisierungsvektor (IV) betrieben werden. DES, der Data Encryption Standard, ist als Algorithmus zwingend von jeder Implementation zu untersttzen, andere Verfahren wie Triple-DES, IDEA, Cast, Blowfish, RC5 usw. knnen optional implementiert werden. Alle diese symmetrischen Verfahren bedingen, dass in jedem Endpunkt einer IPSec-Verbindung (Sicherheitsassoziation) die gleichen, ausreichend langen Schlssel vorliegen. Wie diese Schlssel dorthin gelangen, wird in Kapitel 8 nher beschrieben. Wichtig zu wissen ist an dieser Stelle, dass diese Schlssel vor dem Einsatz des IPSec-ESP-Protokolls, das die Datenverschlsselung implementiert, den beiden Kommunikationspartnern zur Verfgung stehen mssen. Je nach Algorithmus werden Schlssel verschiedener Lnge benutzt. Die am hufigsten in IP Security eingesetzten Algorithmen zur Verschlsselung und die von diesen verwendeten Schlssellngen sind: DES, mit einem 56 Bit langen Schlssel Triple-DES, das einen aus drei 56-Bit-Teilschlsseln bestehenden 168-BitSchlssel bentigt IDEA benutzt einen 128 Bit langen Schlssel Blowfish arbeitet mit einen 448 Bit groen Schlssel Der Einsatz dieser Verfahren, die in der Regel monoalphabetisch sind, muss im CBC-Modus erfolgen. Der Initialisierungsvektor fr diese Betriebsart wird in jedem Paket mit bertragen und dem Chiffretext unmittelbar vorangestellt. In Abbildung 7.1 ist eine Verschlsselung mit dem DES-Algorithmus in IPSec schematisch dargestellt. Man kann hier auch erkennen, wie die Verschlsse-
191
lung die Paketgre verndert, da der Initialisierungsvektor und eventuell notwendige Fllzeichen (Padding) in das Paket mit aufgenommen werden mssen. In diesem Fall, einem zugegebenermaen sehr ungnstig konstruierten, werden die 25 Byte Originaldaten auf 40 Byte vergrert, also um mehr als 60%.
Klartextdaten, 25 Byte PaddingGenerator
Zufallsgenerator
RND
8 Byte
8 Byte
8 Byte
1 7 Byte
IV, 8 Byte
DES
DES
DES
DES
8 Byte
8 Byte
8 Byte
8 Byte
IV, 8 Byte
8 Byte
8 Byte 40 Byte
8 Byte
8 Byte
Abbildung 7.1: IPSec-Datenverschlsselung mit Triple-DES-CBC und explizitem Initialisierungsvektor (IV)
Der Initialisierungsvektor sollte zuflligen Ursprungs sein und mglichst nicht aus dem verwendeten Schlssel des Verschlsselungsprogramms abgeleitet werden. Er kann ungesichert bertragen werden und wird dem Chiffretext in einem IPSec-ESP-Paket direkt vorangestellt. Fr nachfolgende Pakete kann der letzte Chiffretextblock als IV verwendet werden. Im vorliegenden Beispiel ist weiterhin zu sehen, wie der Klartext in fr den jeweiligen Chiffrieralgorithmus passende Teile zerlegt wird. Im Fall von DES oder auch Triple-DES mssen diese Blcke genau 64 Bit gro sein. Falls, wie in Abbildung 7.1, der letzte Block keine 64 Bit (8 Byte) lang ist, muss er mit Fllzeichen auf die erforderliche Lnge aufgefllt werden. Da das DES-Verfahren als mittlerweile nicht mehr ausreichend angesehen wird, um sensible Daten zu schtzen, bieten praktisch alle fr dieses Buch untersuchten IPSec-Implementierungen auch Triple-DES als optionalen Algorithmus an, manche Systeme sogar zustzlich noch Blowfish oder IDEA.
192
7.2.2
Integrittsprfung und Authentifizierung in IPSec
Zum Schutz der Datenintegritt und zur Authentifizierung greift man auf Hash-Algorithmen zurck, die in entsprechenden Betriebsarten sicher vor so genannten Kollisionen sind. Die in IPSec vorgeschriebenen Verfahren sind HMAC-MD5-96 und HMAC-SHA1-96, also Algorithmen, die auf den bekannten Hashfunktionen MD5 und SHA1 aufsetzen. Die Funktionsweise dieser Verfahren ist in Kapitel 4 beschrieben. Diese Verfahren arbeiten ebenfalls mit einem symmetrischen, 128 Bit langen Schlssel, der ausschlielich den beiden Kommunikationsendpunkten bekannt sein darf. Dieser Schlssel wird ebenfalls vom IKE-Protokoll generiert und muss vorhanden sein, sobald IPSec-Pakete bertragen werden. In Abbildung 7.2 ist die generelle Funktion innerhalb IPSec skizziert, wobei die Position des ICV (Integrity Check Value) im ausgehenden Paket vom jeweiligen IPSec-Protokoll abhngig ist. Es hngt auch vom jeweiligen Protokoll ab, welche Bereiche des Pakets gesichert werden. Nheres dazu ist in den Kapiteln zum AH- und ESP-Protokoll zu finden.
Zu sicherndeDaten
128-Bit-Schlssel
HMACMD5-96
ICV, 96 Bit
Zu sicherndeDaten
Abbildung 7.2: In IPSec kann man HMAC-MD5-96 zur Authentifizierung und Integrittsprfung von Datenpaketen einsetzen.
Die Hashverfahren werden nicht direkt eingesetzt, sondern arbeiten im HMAC-Modus, der die Verfahren sicher vor so genannten Kollisionen macht. Eine Kollision liegt dann vor, wenn zwei verschiedene Eingabewerte den gleichen Hashwert erzeugen. Fr das MD5-Verfahren hat man bereits Kollisionen demonstriert, jedoch waren diese eher akademischer Natur. Es gibt zum jetzigen Zeitpunkt keine bekannte mathematische Methode, solche Werte zu berechnen, die einen gleichen Hashwert produzieren, insbesondere dann nicht, wenn sich diese Werte hneln sollen und gleich lang sein mssen. Nichtsdestoweniger hat man das Kollisionsproblem in Fachkreisen zur Kenntnis genommen und lsst als Schutzmanahme dagegen die Hashver-
193
fahren generell im HMAC-Modus arbeiten; aus dem MD5-Verfahren wird z.B. HMAC-MD5-96. Die Zahl 96 bedeutet, dass der Hashwert auf 96 Bit verkrzt wird, indem man die niederwertigen 32 Bit aus dem Wert entfernt. In den RFCs 2403 und 2404 sind die Benutzung der Hash-based Message Authentication Codes auf Basis von SHA1 und MD5 spezifiziert, das HMACVerfahren selbst ist im RFC2104 beschrieben. IPSec erlaubt auch die optionale Verwendung anderer Verfahren zur Integrittssicherung, jedoch sind in heutigen Implementierungen fast ausschlielich HMAC-MD5-96 und HMAC-SHA1-96 zu finden.
7.2.3
Schutz vor Replay-Angriffen
Der Schutz vor wiederholtem Senden von Paketen (Replay-Angriff) wird in IPSec durch den ARS (Anti-Replay Service) gewhrleistet. Zu diesem Zweck ist in jedem IPSec-Paket, egal mit welchem Protokoll es erzeugt wurde, ein 32 Bit groes Feld enthalten, in dem eine monoton steigende Sequenznummer enthalten ist. Sobald eine IPSec-Sicherheitsassoziation aufgebaut wird, wird dieser Zhler mit 0 initialisiert. Obwohl der ARS in IPSec optional ist, wird in ausgehenden Paketen der Zhler immer um eins erhht. Falls auf ARS verzichtet wird, betrifft dies nur den Empfnger, er wertet das Feld in diesem Fall einfach nicht aus. Da die Pakete aufgrund der Wegefindung in IP-Netzen nicht in der Reihenfolge ankommen mssen, in der sie abgeschickt wurden, reicht es nicht aus, im Empfnger zu prfen, ob die Sequenznummer des ankommenden Pakets um eins hher ist als die des vorhergehenden Pakets der entsprechenden Sicherheitsassoziation. Statt dessen verwaltet der Empfnger ein so genanntes Empfangsfenster. Dieses Fenster ist meist 64 Bit, mindestens jedoch 32 Bit gro. Pakete, die innerhalb dieses Fensters ankommen, werden verarbeitet. Pakete, die links davon liegen, sind entweder schon einmal eingetroffen oder kommen schlicht zu spt an und werden verworfen. Falls ein Paket eintrifft, das rechts vom aktuellen Fenster liegt, wird es der IPSec-Integrittsprfung unterworfen. Falls es diese besteht und nur dann , wird das Fenster so weit verschoben, bis das Paket an der rechten Grenze des Fensters steht. In Abbildung 7.3 wird die Funktionsweise an einem 32 Bit breiten ARS-Fenster demonstriert. Das linke Element im Fenster hat den Wert N, wobei N dem Wert des Sequenzzhlers des Pakets entspricht, das an dieser Stelle angekommen ist. Das Paket mit der Sequenznummer N-6 fllt nicht in das Fenster, sondern liegt links davon. Dies bedeutet, dass das Paket entweder zu spt eintrifft oder bereits schon einmal eingetroffen ist, also wird es verworfen. Das Paket N+7 liegt zwar im Bereich des Fensters, ist aber schon einmal angekommen und wird somit auch verworfen. Das Paket N+21 liegt im Fenster, ist auch noch nicht vorher angekommen und kann demnach verarbeitet werden.
194
Das Paket N+40 hingegen liegt rechts des Fensterbereichs. Es wird auf Integritt und Authentizitt geprft, und falls diese Prfung erfolgreich war, wird das Fenster so weit nach rechts verschoben, bis das neue Paket darin erscheint.
Paketfluss Fenstergre=32 Anti-Replay Window
N
Paket N-6 Paket N+7 Paket N+21 Paket N+40
Paketauthentifizierung Paketintegrittsprfung
Anti-Replay Window
Fensterwirdumacht Positionenverschoben
Abbildung 7.3: Der IPSec-Anti-Replay-Service (ARS)
An dieser Stelle vielleicht ein Tipp zur Konfiguration von IPSec-Sicherheitsassoziationen: Viele Implementierungen bieten die vom Standard ausdrcklich zugelassene Mglichkeit an, beim Einsatz der Verschlsselung im ESP-Protokoll auf die explizite Prfung der Integritt und Authentizitt durch HMACMD5-96 oder HMAC-SHA1-96 zu verzichten. In diesem Fall besteht aber leider die Mglichkeit, dass bestimmte Denial-of-Service-Angriffe trotz aktivem ARS ausgefhrt werden. Denn wenn ein Angreifer den Verkehr mitliest und stndig selbst Pakete mit der aufgezeichneten verschlsselten Nutzlast erzeugt, deren Sequenznummern sehr weit rechts auerhalb des Fensters liegen, passieren folgende zwei fatalen Dinge: Erstens wird das Fenster sehr weit nach rechts verschoben, so dass die ordnungsgem eintreffenden Pakete links auerhalb des Empfangsbereichs liegen und daher verworfen werden. Zweitens werden ausgerechnet die geflschten Pakete weiterverarbeitet und durchlaufen die rechenintensive Entschlsselung. IPSec selbst kann nicht mehr erkennen, dass es sich um unzulssige Pakete handelt, das knnen nur noch die hheren Anwendungsschichten, also UDP, TCP oder IP, falls es sich um IPSec im Tunnelmodus handelt. Erst diese Protokolle stellen dann fest, dass bei der Entschlsselung der Pakete ein ziemlicher Unsinn her-
195
ausgekommen ist, da die Daten bereits schon einmal angekommen sind. Bis zu diesem Punkt wurde aber schon einiges an Ressourcen aufgewendet, die an anderer Stelle fehlen. Man sollte also in jedem Fall die explizite Paketintegrittsprfung und Paketauthentifizierung benutzen, auch bei der Verschlsselung der Daten. Die verwendeten Algorithmen und Systeme sind mittlerweile recht schnell, so dass hierdurch keine nennenswerten Leistungseinbuen entstehen.
7.3
Die Standardisierung von IPSec ist recht weit fortgeschritten. In den RFCs 2401 bis 2412 und einigen anderen, darin angesprochenen Dokumenten ist alles Wissenswerte ber IP Security nachzulesen.
7.3.1
Die IPSec-Architektur
Die Architektur von IPSec ist in einer Reihe von RFCs zusammengefasst, die im folgenden Kapitel beschrieben sind. Die IPSec-Architektur selbst knnen Sie als bersicht in Abbildung 7.4 sehen.
Architektur
ESP
AH
Verschlsselungsalgorithmus
Authentifizierungsalgorithmus
IPSec Domain of Interpretation (DOI)

Schlsselverwaltung
Anwendungsstrategie
Abbildung 7.4: Die Architektur von IP Security
196
Ausgehend von dieser Architektur und den jeweiligen Anwendungsstrategien, ergeben sich folgende typische Kombinationen von IPSec-Diensten: ESP mit Verschlsselung, Integrittsprfung, Authentifizierung und ARS ESP mit Verschlsselung, Integrittsprfung und Authentifizierung ESP mit Verschlsselung und ARS ESP mit Verschlsselung ESP mit Integrittsprfung, Authentifizierung und ARS ESP mit Integrittsprfung und Authentifizierung AH mit Integrittsprfung, Authentifizierung und ARS AH mit Integrittsprfung und Authentifizierung Weiter differenzieren kann man dies noch durch die verschiedenen Algorithmen, die fr die verschiedenen Dienste zur Verfgung stehen. Im Bereich des Schlsselmanagements kann die Anwendungsstrategie festlegen, wie dieses zu erfolgen hat und auf welche Art sich die Kommunikationspartner gegenseitig authentifizieren. Diesem Teil, dem Internet Key Exchange (IKE), ist Kapitel 8 gewidmet.
7.3.2
Die aktuelle IPSec-Standardisierung
IPSec ist sowohl fr IP Version 4 als auch fr Version 6 in einer Reihe von RFCs standardisiert. Die folgende Aufzhlung ist nicht vollstndig, es werden nur die wichtigsten Dokumente beschrieben, die fr das Verstndnis von IP Security notwendig sind. RFC 2401: Security Architecture for the Internet Protocol Dieses Dokument beschreibt die Basisarchitektur von IPSec-Systemen. Es werden verschiedene Sicherheitsdienste fr den Datenverkehr auf IP-Ebene festgelegt. Das Zusammenspiel der unterschiedlichen Komponenten, die ein IPSec-System ausmachen, wird ebenso festgelegt wie die Implementierung einer Sicherheitspolitik auf Netzwerkebene und das Konzept der Sicherheitsassoziation. RFC 2402: IP Authentication Header Dieser RFC erlutert, wie die Integritt und Authentizitt von IP-Datagrammen durch Einsatz von entsprechenden Algorithmen sicherzustellen ist. Weiterhin wird der Schutz gegen so genannte Replay-Angriffe beschrieben.
197
RFC 2403: The Use of HMAC-MD5-96 within ESP and AH In diesem Papier wird festgelegt, wie der MD5-Algorithmus in Verbindung mit dem HMAC-Verfahren in den IPSec-Protokollen ESP und AH zur Integrittsprfung und Authentifizierung eingesetzt wird. RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH Dieses Dokument beschreibt, wie der MD5-Algorithmus in Verbindung mit dem HMAC-Verfahren in den IPSec-Protokollen ESP und AH zur Integrittsprfung und Authentifizierung verwendet wird. RFC 2405: The ESP DES-CBC Cipher Algorithm with explicit IV Dieser Request for Comments legt fest, wie der DES-Algorithmus zum Verund Entschlsseln von Datagrammen im Cipher-Block-Chaining-Modus (CBC) einzusetzen ist. Ebenso wird angegeben, wie der Initialisierungsvektor in IPSec zu behandeln ist. RFC 2406: IP Encapsulating Security Payload (ESP) Hierin wird das am hufigsten eingesetzte IPSec-Protokoll beschrieben, das alle Dienste zur Sicherstellung von Vertraulichkeit, Integritt und Authentizitt der Datagramme sowie Mechanismen zum Schutz gegen Replay-Angriffe zur Verfgung stellen kann. RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP Dieses Papier spezifiziert Datenformate, Strukturen, Konstanten und Richtlinien, mit denen ISAKMP eine Sicherheitsassoziation fr IPSec erzeugen kann. RFC 2408: Internet Security Association and Key Management Protocol Dieses im Vergleich zu den anderen IPSec-RFCs recht umfangreiche Dokument beschreibt das Internet Security Association and Key Management Protocol, oder kurz ISAKMP. Dies ist ein von speziellen Verschlsselungsalgorithmen oder Schlsselerzeugungstechniken unabhngiges Rahmenwerk, das als Grundlage fr konkrete Schlsselmanagement-Protokolle wie z.B. IKE dient. RFC 2409: The Internet Key Exchange IKE, das Internet Key Exchange Protocol, ist das Thema dieses Papiers. Dieses Protokoll beschreibt, wie Sicherheitsassoziationen ausgehandelt werden, wie symmetrische Schlssel erzeugt werden und wie sich die beiden Gegenstellen gegenseitig authentifizieren. Es werden auch alle Manahmen zum Schutz gegen eine Reihe von Angriffen wie Spoofing, Denial-of-Service usw. beschrieben.
198
Die IPSec-Sicherheitsassoziation
RFC 2412: The OAKLEY Key Determination Protocol Dieser RFC beschreibt das OAKLEY-Protokoll, das die sichere Erzeugung von Schlsseln auf zwei Gegenstellen auf Basis des Diffie-Hellman-Verfahrens beschreibt. Einige Teile dieses Protokolls sind auch Bestandteil von IKE. RFC 2451: The ESP CBC-Mode Cipher Algorithms In diesem Standard wird erlutert, wie verschiedene, optionale Verschlsselungsalgorithmen im ESP-Protokoll von IPSec eingesetzt werden.
7.4
Die IPSec-Sicherheitsassoziation
Eine Sicherheitsassoziation (SA) ist das Fundament von IPSec. Sie bestimmt das Verhalten dieses Sicherheitsprotokolls, also welche Verschlsselungsalgorithmen verwendet werden, die Lebensdauer der SA, das Authentifizierungsprotokoll usw. Die verschiedenen SAs werden in der Security Association Database (SAD) gespeichert. Eine Sicherheitsassoziation ist immer unidirektional. Dies bedeutet, wie in Abbildung 7.5 gezeigt, dass in der Praxis fr bidirektionalen Datenverkehr immer mindestens zwei SAs zwischen den Kommunikationsendpunkten existieren mssen. In diesem Fall hat jedes der beiden Systeme eine eingehende (Inbound-SA) und eine ausgehende (Outbound-SA) Sicherheitsassoziation. Es knnen aber durchaus auch mehrere SAs ber eine Verbindung existieren, wenn Pakte mit unterschiedlichen Sicherheitsstufen transportiert werden mssen.
IPSecGateway Privates (sicheres) Netzwerk Unsicheres Netzwerk IPSecGateway Privates (sicheres) Netzwerk
Dest Cipher: Auth: ARS: PFS: SA-Life .... ....
141.28.1.5 3-DES-CBC HMAC-MD5-96 True True 8 Hrs Dest Cipher: Auth: ARS: PFS: SA-Life .... ....
Inbound-SA Outbound-SA
141.28.156 3-DES-CBC HMAC-MD5-96 True True 8 Hrs
Outbound-SA Inbound-SA
Abbildung 7.5: Die Sicherheitsassoziationen in IPSec sind unidirektional.

199
Der Security Parameter Index (SPI), der in jedem IPSec-Protokollheader eingetragen ist, ordnet jedes Paket eindeutig einer SA zu. Denn falls innerhalb einer IP-Verbindung mehrere SAs mit dem gleichen Protokoll existieren, die sich z.B. nur in der Strke der Verschlsselung unterscheiden, dann ist der SPI der einzige eindeutige Wert, denn die Quell- und die Zieladresse sowie Protokollnummer wren in jedem IP-Paket gleich. Eine weitere, allerdings in keinem Standard festgelegte Verwendung des SPI findet man kleinen SOHO-Routern (Small Office Home Office) verschiedener Hersteller, die ihre Verbindung zum Internet ber Whlverbindungen mit dynamischer Zuweisung von IP-Adressen herstellen. Ohne den Einsatz von IPSec wurden die verschiedenen Rechner hinter diesem Router per NAT/PAT (Network Address Translation/Port Address Translation) auf die vom ISP zugewiesene IP-Adresse abgebildet, indem man ihre TCP- oder UDP-Portnummern ndert und der Router eine Tabelle pflegt, in der die privaten Adressen den Portnummern zugewiesen werden. Mit IPSec ist dies nicht mglich. Erstens besitzen ESP oder AH berhaupt keine Portnummern, und zweitens werden die Pakete auf Integritt geprft. Mit AH funktioniert dies demnach gar nicht. Mit ESP, das den ueren Header nicht auf Integritt prft, kann man eine andere Verteilungsstrategie der Pakete im privaten Netz einsetzen. Da der SPI eindeutig ist, kann man im Router eine Tabelle pflegen, in der die Pakete aufgrund des SPI dem richtigen Rechner zugeordnet sind. Allerdings funktioniert dies nur, wie in Kapitel 8 erklrt wird, wenn die Rechner IKE im so genannten Aggressive Mode einsetzen, was die meisten PC-Implementierungen aber knnen. SAs werden in der Regel durch das IKE-Protokoll erzeugt. Falls die IPSecSicherheitsstrategie ein Paket prft, das IPSec-Diensten zugefhrt werden muss, wofr aber noch keine Sicherheitsassoziation existiert, dann startet IPSec das IKE-Protokoll, um diese zu generieren. Sobald dieser Prozess abgeschlossen ist, kann das Paket ordnungsgem verarbeitet und anschlieend bertragen werden. Die manuelle Erzeugung von SAs wird im Standard ebenfalls bercksichtigt, ist aber wegen der Fehleranflligkeit und der immanenten Sicherheitsprobleme in fast keinem System implementiert. Das Lschen von Sicherheitsassoziationen erfolgt durch das Protokoll, das sie erzeugt hat, meist IKE. Die Grnde hierfr liegen entweder in der Sicherheitsstrategie, wenn die Lebensdauer der SA abgelaufen ist oder wenn die maximale Anzahl von Bytes, die innerhalb der SA bertragen wurden, berschritten ist. Oder die Gegenstelle verlangt, dass die SA gelscht wird, beispielsweise weil ein neuer Schlssel ausgetauscht wird.
200
Die IPSec-Security-Policy
Eine Sicherheitsassoziation pflegt eine Datenbank, in der Felder bzw. Strukturen enthalten sind, die fr den Betrieb der SA notwendig sind. Diese Felder sind: Sequence Number Dies ist der Sequenzzhler fr ausgehende Pakete. Anti-Replay Window Dies ist das ARS-Fenster. Es wird fr ankommende Pakete verwendet. Sequence Number Overflow Dieses Feld gibt an, ob nach einem berlauf des Sequenzzhlers noch weiter bertragen werden darf und damit die SA weiter existieren kann. Lifetime Dieses Feld enthlt die Lebensdauer der SA durch Angabe der zeitlichen Lnge, der Anzahl der maximal zu bertragenden Bytes oder beides. Es gibt darber hinaus auch zwei Arten der Lifetime, eine, die die SA sofort nach Eintritt der Terminierungskondition beendet (hard), und eine andere (soft), die dem IPSec-Kernel eine Nachricht schickt, damit dieser eine neue SA erzeugen kann und die Kommunikation nicht unterbrochen wird. Mode Hier wird angezeigt, ob IPSec innerhalb dieser SA im Tunnel- oder Transportmodus arbeitet. Tunnel Destination Hier steht, falls es sich um einen IPSec-Tunnelmodus handelt, die IP-Zieladresse des ueren Headers. PMTU Parameters Bei IPSec im Tunnelmodus werden die PMTU-Informationen, die man zur Fragmentierung bentigt, in dieser Struktur gespeichert.
7.5
7.5.1
Die IPSec-Security-Policy
Die Security Policy in IPSec
Die Sicherheitsstrategie oder Security Policy in IPSec legt fest, welche Dienste auf ein- oder ausgehende Pakete anzuwenden sind. Die Regeln, aus denen sich diese Strategie zusammensetzt, sind in einer speziellen Datenbank, der
201
Security Policy Database (SPD) abgelegt. Diese Strategie whlt eine von drei Arten aus, wie die Pakete behandelt werden. Die Pakete werden entweder verworfen (discard), nicht durch einen IPSec-Dienst transformiert und sofort weiterbearbeitet (bypass) oder durch IPSec umgeformt (apply) und dann weiterverarbeitet. Fr ausgehende Pakete liefert die SPD im letzten der drei Flle (apply) einen Verweis auf einen Eintrag in der Security Association Database, in der die spezifischen Optionen und Parameter hinterlegt sind, mit denen eine Sicherheitsassoziation aufgebaut oder bereits unterhalten wird. Falls die ausgewhlte SA noch nicht aktiv ist, wird ein Key-Management-Protokoll, in der Regel IKE, gestartet, um sie zu etablieren. Erst dann wird das Paket bertragen. Die Security Policy Database ist eine Datenstruktur im Kernel (Kernbereich) des Betriebssystems, auf dem der IPSec-Stack implementiert ist. Auf Applikationsebene mssen entsprechende Werkzeuge zum ndern, Lschen und Hinzufgen von Eintrgen existieren. Zunehmend werden auch Schnittstellen zu netzwerkweiten Verzeichnisdiensten wie LDAP eingesetzt, um eine bergreifende Sicherheitsstrategie einsetzen zu knnen.
7.5.2
Die IPSec-Selektoren
Die Security Policy Database enthlt verschiedene Selektoren, mit denen festgelegt wird, welche Dienste auf bestimmte Pakete angewendet werden. Folgende Informationen aus dem IP-, TCP- und UDP-Header der zu inspizierenden Pakete knnen als Selektoren benutzt werden: Zieladresse Quelladresse Protokoll Portnummer (des Transportprotokolls) Name Zieladresse Die IP-Zieladresse kann in Form von Adressbereichen, Netzwerken, Hostadressen oder ohne weitere Spezifikation (Wildcard) angegeben werden. IPSecGateways benutzen in der Regel keine Hostadressen und bieten daher allen dahinter liegenden privaten Systemen Schutz. Quelladresse Die IP-Quelladresse kann ebenfalls in Form von Adressbereichen, Netzwerken, Hostadressen oder als Wildcard angegeben werden.
202
IPSec-Betriebsmodi
Protokoll Dieser Selektor bezieht sich, sofern vorhanden, auf das Protokollfeld des Transportprotokolls. Falls kein Transportprotokoll verwendet wird, z.B. beim Verschachteln von IPSec-SAs, dann wird das Feld nicht verwendet. Portnummer (des Transportprotokolls) Dieser Selektor bezieht sich auf das Tupel aus Ziel- und Ursprungsportnummer des Transportprotokolls (TCP, UDP, ...). Auch hier knnen Wildcards benutzt werden. Name Dieses Feld wird im Augenblick von IPSec nicht benutzt. Es wird momentan nur vom IKE-Protokoll als Selektor verwendet.
7.6
7.6.1
IPSec-Betriebsmodi
Tunnelmodus
Der Tunnelmodus wird eingesetzt, um komplette IP-Pakete einschlielich Header zu schtzen. Dies wird erreicht, indem ein neues IP-Paket erzeugt wird, in dessen Datenbereich das zu bertragende Paket eingefgt wird. Auf diese Weise erreicht man auch eine weitgehende Vertraulichkeit des Verkehrsflusses, da ein Angreifer beim Einsatz des ESP-Protokolls keinerlei Informationen ber das Originalpaket erhlt. Alle Adressen und Protokollnummern des Originalpakets sind verschlsselt. Der Tunnelmodus kann in allen drei IPSec-Einsatzszenarien verwendet werden, also in Gateway-zu-Gatway-, Host-zu-Gateway- und Host-zu-Host-Verbindungen. Im Gegensatz zu anderen Tunneling-Protokollen, die es erlauben, auch Pakete anderer Netzwerkprotokolle, wie z.B. IPX, einzukapseln, ist mit IPSec nur IPin-IP-Tunneling mglich.
7.6.2
Transportmodus
Der IPSec-Transportmodus wird benutzt, um hhere Protokollschichten zu schtzen, die im Datenbereich der IP-Pakete eingekapselt sind. Der PaketOverhead ist im Gegensatz zum Tunnelmodus etwas geringer, da kein zustzlicher IP-Header konstruiert werden muss.
203
Der Transportmodus kann ausschlielich in IPSec-Host-zu-Host-Verbindungen benutzt werden, da der Kommunikationsendpunkt auch gleichzeitig der Sicherheitsendpunkt ist. Weiterhin knnen sich Angreifer Informationen ber die Netzwerkstruktur und internen Verkehrsbeziehungen verschaffen selbst beim Einsatz der Verschlsselung im ESP-Modus, die in diesem Fall nur auf das hhere Protokoll angewendet wird. Protokollnummern geben weiterhin Aufschluss ber eingesetzte Anwendungen.
7.7
IPSec-Einsatzszenarien
Abhngig davon, wo die IPSec-Verbindungen initiiert und terminiert werden, kann man die mglichen Einsatzszenarien in drei Gruppen unterteilen, die in vielen praktischen Fllen auch gemischt eingesetzt werden knnen: Gateway-zu-Gateway Host-zu-Gateway Host-zu-Host
IPSecGateway IPSecGateway
Privates (sicheres) Netzwerk
Unsicheres Netzwerk
IPSec-SA
Gateway-zu-Gateway IPSecClientsoftware
IPSecGateway
Unsicheres Netzwerk
IPSec-SA
Host-zu-Gateway IPSecClientsoftware IPSecClientsoftware
Unsicheres Netzwerk
IPSec-SA
Host-zu-Host
Abbildung 7.6: Die verschiedenen IPSec-Einsatzszenarien
204
IPSec-Protokolle
7.7.1
Gateway-zu-Gateway
Hier erfolgt der Schutz der IP-Datagramme durch IPSec zwischen zwei Gateways. Es sind meist VPN-Gateways oder Router. Der Haupteinsatzzweck ist die Verbindung von privaten Netzen ber unsichere Verbindungswege.
7.7.2
Host-zu-Gateway
Hier erfolgt der Schutz der IP-Pakete auf dem Transport von einem Endgert (Host) zu einem Gateway. Ein typisches Einsatzgebiet ist Remote Access ber unsichere Transportnetze.
7.7.3
Host-zu-Host
Dieses Szenario, in dem zwischen Endsystemen IP-Datagramme bertragen werden, trifft man selten an. Ein mgliches Einsatzgebiet sind Intranet-VPNs.
7.8
7.8.1
IPSec-Protokolle
Die Paketverarbeitung in IPSec
Ausgehende Pakete Ausgehende Pakete werden von der hheren Schicht (Transportebene) an das IP-Protokoll weitergegeben. Es erfolgt eine Abfrage in der Security Policy Database, was mit dem betreffenden Datagramm geschehen soll. Abhngig von den Informationen ber das Paket gibt es folgende drei Mglichkeiten: Discard (Fallenlassen), das Datagramm wird verworfen. Bypass (Umgehen), das Datagramm umgeht IPSec und wird verschickt. Apply (Anwenden), es wird ein Verweis auf eine SA zurckgeliefert, das Datagramm entsprechend verarbeitet und anschlieend verschickt. Falls IPSec feststellt, dass fr das betreffende Paket im dritten Fall (Apply) noch keine SA existiert, wird das IKE-Protokoll aufgerufen, um die notwendige Sicherheitsassoziation zu erzeugen. Das Paket wird erst bertragen, nachdem die SA erzeugt wurde. Eingehende Pakete Diese Verarbeitung unterscheidet sich grundstzlich von der ausgehender Pakete. Bei eingehenden Paketen prft die IPSec-Schicht zuerst, ob es sich um ein IPSec-Paket handelt und ob dafr bereits eine Sicherheitsassoziation aufgebaut wurde. Falls keine SA existiert, wird das IPSec-Paket sofort fallen gelassen. Im anderen Fall wird aufgrund der Informationen in der Security Association Database die notwendige Transformation des Pakets durchgefhrt.
205
Falls das Paket kein IPSec-Paket ist, wird geprft, ob auf das Paket eine Security Policy anwendbar ist. Wenn dies der Fall ist, aber keine Sicherheitsassoziation dafr besteht, wird das Paket sofort verworfen. Wenn keine Security Policy anwendbar ist, wird das IP-Paket an die nchsthhere Verarbeitungsschicht weitergereicht. Dieses Verhalten gilt fr normale IP/IPSec-Stack-Implementierungen; spezielle gehrtete Implementierungen verwerfen sofort alle Nicht-IPSecPakete, auer UDP-Paketen mit der Portnummer 500, die vom IKE-Protokoll benutzt werden. Standard-konform ist dieses Verhalten allerdings mit hherem Verarbeitungsaufwand und geringerer Sicherheit dadurch erreichbar, dass eine Sicherheitsstrategie existiert, die alle mglichen IP-Pakete umfasst.
7.8.2
Das Authentication-Header-Protokoll (AH)
Authentication Header Authentication Header ist ein IPSec-Protokoll, das auer der Datenvertraulichkeit alle in IPSec geforderten Schutzmechanismen bietet. Die detaillierte Spezifikation ist im RFC2402 nachzulesen. Die Hauptaufgabe des AH besteht in der Authentifizierung der Datenpakete und der Sicherung ihrer Integritt. Optional kann man den Schutz vor wiederholtem Senden von Datagrammen (Replay-Angriffen) aktivieren.
Originales IP-Paket
Neuer IPHeader
IP
TCP
Daten
IPSec-AH im Tunnelmodus
IP
AH
IP
TCP
Daten
Authentifizierter Bereich
Originales IP-Paket
IP TCP Daten
IPSec-AH im Transportmodus
IP
AH
TCP
Daten
Abbildung 7.7: Das IPSec-Authentication-Header-Protokoll (AH)
Der Schutz der Datenintegritt erstreckt sich ber das vollstndige IP-Paket, also auch ber den IP-Header. Somit kann auch keinerlei Form von NAT (Net-
206
IPSec-Protokolle
work Address Translation, Umsetzung von IP-Adressen) auf Pakete angewendet werden, die mit dem Authentication Header gesichert wurden. Falls dies in bestimmten Fllen ein Problem sein sollte, muss man das ESP-Protokoll einsetzen. Da sich einige Werte im IP-Header whrend des Transports ndern knnen, drfen die betreffenden Felder natrlich nicht in den Prfwert eingehen und werden von der Berechnung mit 0 bewertet. Diese fnf Felder sind: Type of Service, Flags, Fragment Offset, Time to Live und Header Checksum. Das Authentication-Header-Protokoll wird im IP-Header durch die Protokollnummer 51 gekennzeichnet. Der eigentliche Header, der zwischen IP-Header und Nutzdaten eingefgt wird, ist recht einfach aufgebaut. Es werden auch keine Trailer oder Fllzeichen bentigt, wodurch die Pakete nicht so sehr vergrert werden. In IP Version 4 hat der Authentication Header meist eine Lnge von 24 Byte, die sich allerdings bei Einsatz anderer optionaler HMAC-Verfahren unter Umstnden vergrern kann. Der Authentication Header setzt sich aus den im Folgenden erluterten Feldern zusammen (vgl. Abbildung 7.8): Next Header Dieses Feld zeigt an, welche Art von Daten auf den Authentication Header folgt. Im Tunnelmodus ist dies immer der Wert 4 (IP). Im Transportmodus hngt dies von den Nutzdaten ab. Dies sind meist TCP- oder UDP-Pakete.
0
7
15
31
Neuer IP-Header
Authentication Header
Next Header Payload Length
Reserved
Security Parameter Index (SPI) Sequence Number (Anti-Replay Service)

Integrity Check Value (ICV), Authentifizierungsdaten
Eingekapseltes IP-Paket
Abbildung 7.8: Das IPSec-AH-Paketformat
207
Payload Length Dieses Feld gibt die Lnge des Headers an. Da, wie eingangs erwhnt, IPSec ein Protokoll aus IP Version 6 ist, erfolgen die Berechnungen auch entsprechend dem RFC2460 in Vielfachen von 64-Bit Werten. Reserved Dieses Feld ist fr zuknftige Erweiterungen reserviert und hat den Wert 0. Security Parameter Index (SPI) Der Security Parameter Index ist eine innerhalb eines IPSec-Systems eindeutige 32-Bit Zahl, die zusammen mit der Zieladresse des ueren IP-Headers eindeutig eine Sicherheitsassoziation identifiziert. Sequence Number In diesem Feld ist der Wert eines 32-Bit-Zhlers enthalten, der bei jedem neuen IP-Paket um eins erhht wird. Er dient auf der Empfngerseite zum Schutz vor wiederholtem Senden von Datagrammen. Integrity Check Value (ICV), Authentication Data Hier stehen die eigentlichen Informationen zur Authentifizierung und Integrittsprfung, der so genannte ICV (Integrity Check Value). Mit welchem Verfahren die Werte erzeugt wurden, wird nicht im AH-Protokoll festgelegt, sondern vorher vom IKE-Protokoll oder manuell spezifiziert. Vom Standard werden HMAC-MD-96 und HMAC-SHA-96 vorgeschrieben, andere Verfahren knnen optional implementiert werden. Die Verarbeitung ausgehender Pakete Im Transportmodus wird der AH-Header direkt nach dem IP-Header in das IP-Paket eingefgt. Im Next-Header-Feld wird die Nummer des Protokolls eingetragen, das im Nutzdatenbereich eingekapselt ist. Das SPI-Feld erhlt die Nummer aus der entsprechenden SA, ebenso wird der Wert des Sequenzzhlers auf einen gltigen Wert gesetzt, also um eins gegenber dem letzten Paket erhht, das innerhalb dieser SA bertragen wurde. Das Protokollfeld im IP-Header wird auf 51 (AH) gesetzt. Im Tunnelmodus erhlt das Feld Next Header den Wert 4, und der AH wird zwischen dem inneren und dem ueren IP-Header eingefgt. Die restlichen Felder werden wie im Transportmodus behandelt. Dann wird ein neuer IPHeader mit der Senderadresse des Gerts und der Zieladresse, die in der SA festgelegt wurde, erzeugt und das Protokollfeld auf 51 gesetzt.
208
IPSec-Protokolle
Die restliche Verarbeitung ist bei Tunnel- und Transportmodus gleich. Das Paket wird mit dem in der Sicherheitsassoziation spezifizierten Authenticator authentifiziert, und der Wert wird in das Authentication-Data-Feld eingetragen. Dabei ist zu beachten, dass im Gegensatz zu ESP das vollstndige IPPaket berechnet wird, inklusive des neuen IP-Headers. Dies bedeutet, dass AH mit keiner Art von NAT (Network Address Translation) eingesetzt werden kann! Von der Berechnung des ICV werden nur die Felder ausgenommen, die sich whrend der bertragung ndern knnen. Als Letztes wird die Paketprfsumme berechnet und in den IP-Header eingetragen. Nun kann das Paket verschickt werden. Die Verarbeitung eingehender Pakete Die Verarbeitung eingehender AH-Pakete erfolgt in umgekehrter Reihenfolge. Bevor die eigentliche Verarbeitung erfolgen kann, muss aufgrund von SPI und IP-Quell- und Zieladressen in der Security Association Database (SAD) ein entsprechender Eintrag mit den notwendigen Optionen und Parametern gefunden werden. Anschlieend wird berprft, ob das Paket schon einmal eingetroffen ist. Hierzu wird, falls diese Option (ARS) im Empfnger aktiviert ist, der Sequenzzhler im AH-Header ausgewertet und geprft, ob sich der Zhlerwert im Empfangsfenster befindet. Falls dem so ist, wird der HMAC des Pakets vom Empfnger berechnet und mit dem Wert im Paket verglichen. Sind beide gleich, so wurde das Paket nicht verndert, ist also authentisch, und aufgrund des Next-Header-Feldes wird geprft, wie das Paket weiter verarbeitet werden soll. Ist in dem Feld eine 4 (IP) eingetragen, so handelt es sich um ein Paket im Tunnelmodus, und das eingekapselte Paket wird entpackt und der nchsthheren Verarbeitungsschicht zugefhrt. Steht in diesem Feld ein anderer Wert, dann wird das vorliegende Paket sofort zur entsprechenden Verarbeitungsschicht weitergeleitet.
7.8.3
Das Encapsulating-Security-Payload-Protokoll (ESP)
Das Encapsulating-Security-Payload-Protokoll bietet alle Sicherheitsfunktionen, die auch AH bietet, plus einem zustzlichen Schutz der Datenvertraulichkeit. Um dies zu erreichen, wird ein Teil des IP-Pakets verschlsselt und ein Header sowie ein Trailer in das Datagramm eingefgt. Die Datenintegrittsprfung und Authentifizierung erstreckt sich im Gegensatz zum Authentication Header nicht ber das vollstndige Paket, sondern der IP-Header wird von der Berechnung ausgenommen. ESP ist ebenfalls ein IP-Protokoll, ihm wurde die Nummer 50 zugeordnet.
209
Ebenso wie beim Authentication Header sind die Algorithmen, die zur Integrittsprfung und zur Verschlsselung benutzt werden, nicht im ESP-Protokoll spezifiziert, sondern bereits vom IKE-Protokoll oder manuell festgelegt worden. ESP muss mindestens einen der beiden Sicherheitsmechanismen Verschlsselung oder Integrittsprfung untersttzen. Es ist also mglich, ESP mit Verschlsselung, ESP mit Integrittsprfung oder ESP mit Verschlsselung und Integrittsprfung zu betreiben, nicht jedoch ESP ohne eines dieser beiden Verfahren. Die erste Variante ohne Integrittsprfung und Authentifizierung birgt aber gewisse Sicherheitsrisiken und sollte mglichst vermieden werden.
Originales IP-Paket
Neuer IPHeader
IP
TCP
Daten
IPSec-ESP im Tunnelmodus
IP
ESP
IP
TCP
Daten
Auth
Verschlsselter Bereich
Originales IP-Paket
IP TCP Daten
IPSec-ESP im Transportmodus
IP
ESP TCP
Daten
Auth
Verschlsselter Bereich
Abbildung 7.9: Das IPSec-Encapsulating-Security-Payload-Protokoll (ESP)
Encapsulating Security Payload fgt dem originalen Datagramm unter Umstnden mehr an zustzlicher Lnge hinzu als das AH-Protokoll, mindestens jedoch 4 Byte mehr. Der ESP-Header folgt direkt auf den IP-Header, und der ESP-Trailer mit den Authentifizierungsdaten wird direkt an die Nutzdaten angehngt. Es sind folgende Felder spezifiziert (siehe Abbildung 7.10):
210
IPSec-Protokolle
15
31
Neuer IP-Header Security Parameter Index (SPI) Sequence Number (Anti-Replay Service) Initialisierungsvektor (IV)
Authentifiziert
Verschlsselt
Eingekapseltes IP-Paket
Padding Padding Len. Next Header Integrity Check Value (ICV), Authentifizierungsdaten
Abbildung 7.10: Das IPSec-ESP-Paketformat
Security Parameter Index (SPI) Der Security Parameter Index ist eine innerhalb eines IPSec-Systems eindeutige 32-Bit-Zahl, die zusammen mit der Zieladresse des ueren IP-Headers eindeutig eine Sicherheitsassoziation identifiziert. Sequence Number (Anti Replay Service) In diesem Feld ist der Wert eines 32-Bit-Zhlers enthalten, der bei jedem neuen IP-Paket um eins erhht wird. Er dient auf der Empfngerseite zum Schutz vor dem wiederholten Senden von Datagrammen. In abgehenden Paketen wird der Zhler immer hochgezhlt, so dass die Entscheidung, ob er benutzt wird, ausschlielich auf der Empfngerseite liegt. Initialisation Vector Der Initialisierungsvektor ist eine 64 Bit groe Zufallszahl, die fr den CipherBlock-Chaining-Modus (CBC) bentigt wird. Dieser Modus ist im RFC2405 als DES-Betriebsart vorgeschrieben. Padding Das Padding (Auffllen) wird im ESP-Protokoll fr verschiedene Zwecke verwendet. Bestimmte Verschlsselungsalgorithmen setzen voraus, dass die zu verschlsselnden Daten ein Vielfaches einer bestimmten Blockgre sind.
211
Beim DES-Verfahren zum Beispiel ist diese Blockgre 64 Bit. Nutzdaten, die kein Vielfaches davon sind, werden auf die erforderliche Lnge aufgefllt. Eine weitere Verwendung besteht darin, auch wenn gar keine Verschlsselung in ESP spezifiziert wurde, die beiden Felder Padding Length und Next Header an ihre richtige Position zu bringen. In Verbindung mit einem Verschlsselungsalgorithmus kann man durch das Padding auch die Lnge der Originaldaten verschleiern und damit ESP ohne Integrittsprfung vor so genannten Cut-and-Paste-Angriffen schtzen. Padding Length In diesem Feld ist festgelegt, wie lang das Padding-Feld ist. Eine 0 zeigt an, dass kein Padding verwendet wurde. Next Header Dieses Feld gibt an, welche Art von Daten im Nutzdatenfeld enthalten ist, im Tunnelmodus ist dies immer der Wert 4 (IP), im Transportmodus meist 6 (TCP) oder 17 (UDP). Integrity Check Value (ICV), Authentication Data Hier stehen die eigentlichen Informationen zur Authentifizierung und Integrittsprfung, der so genannte ICV (Integrity Check Value). In ESP ist die Authentifizierung optional; falls keine ausgewhlt wurde, entfllt dieses Feld. Die Verarbeitung ausgehender Pakete Im Transportmodus wird der ESP-Header direkt nach dem IP-Header in das IP-Paket eingefgt und der ESP-Trailer an das Paket angehngt. Im Next-Header-Feld wird die Nummer des Protokolls eingetragen, das im Nutzdatenbereich eingekapselt ist. Das SPI-Feld erhlt die Nummer aus der entsprechenden SA, ebenso wird der Wert des Sequenzzhlers auf einen gltigen Wert gesetzt, also um eins gegenber dem letzten Paket erhht, das innerhalb dieser SA bertragen wurde. Falls notwendig, werden Fllzeichen eingefgt und das Feld Padding Length auf den entsprechenden Wert gesetzt. Das Protokollfeld im IP-Header wird auf 50 (ESP) gesetzt. Im Tunnelmodus umschlieen ESP-Header und -Trailer das eingekapselte IPPaket. Das Feld Next Header erhlt bei IP Version 4 den Wert 4. Die restlichen Felder werden wie im Transportmodus behandelt. Dann wird ein neuer IPHeader mit der Senderadresse des Gerts und der Zieladresse, die in der SA festgelegt wurde, erzeugt und das Protokollfeld auf 50 gesetzt. Die restliche Verarbeitung ist bei Tunnel- und Transportmodus identisch. Es wird zunchst alles zwischen dem Initialisierungsvektor und dem ESPAuthentication-Data-Feld mit dem Verschlsselungsalgorithmus verschlsselt, der fr die angewendete SA festgelegt wurde. Daraufhin wird das Paket
212
IPSec-Protokolle
vom ESP-Header bis zum ESP-Trailer mit dem in der Sicherheitsassoziation spezifizierten Authenticator authentifiziert und der Wert in das Authentication-Data-Feld eingetragen. Als Letztes wird die Paketprfsumme berechnet und in den IP-Header eingetragen. Nun kann das Paket verschickt werden. In Abbildung 7.11 ist die Verarbeitung eines ESP-Pakets im Tunnelmodus skizziert. Die IPSec-Security-Policy prft zuerst anhand ihrer Datenbank, ob fr das zu versendende Paket eine Regel zutrifft, und liefert im Erfolgsfall einen Verweis auf einen Eintrag in der Sicherheitsassoziationsdatenbank (SAD) zurck. In dieser Datenbank sind alle Parameter und Optionen hinterlegt, die IPSec bentigt, um eine Sicherheitsassoziation aufzubauen bzw. zu unterhalten. Im Falle unseres Beispiels existiert ein entsprechender Eintrag, und es ist auch bereits eine Sicherheitsassoziation aktiv, innerhalb derer das Paket transportiert werden kann. In der SAD ist genau festgelegt, wie das zu bertragende Paket bearbeitet werden muss (Tunnelparameter, Verschlsselungsalgorithmus, Schlssel, Authentifizierungsalgorithmus, SPI, letzter Wert des Sequenzzhlers usw.).
Security Policy
Neuer IPHeader
IP
TCP
Daten
Paket-Einkapselung
IP
Security Association Database SPI, Seq-Ctr.
ESP
IP
TCP
Daten
3-DES, Keys 1-3.
Triple-DES-CBC DES
IP
ESP
HMAC-SHA1-96
HMAC-SHA-1-96, Key
IP
ESP
Verschlsselter Bereich Authentifizierter Bereich
Auth
Abbildung 7.11: Die Verarbeitung eines ausgehenden IPSec-ESP-Pakets
213
Die Verarbeitung eingehender Pakete Die Verarbeitung eingehender Paket erfolgt in genau umgekehrter Reihenfolge. Bevor die eigentliche Verarbeitung erfolgen kann, muss aufgrund von SPI und IP-Quell- und Zieladressen in der SAD ein entsprechender Eintrag mit den notwendigen Optionen und Parametern gefunden werden. Dann wird berprft, ob das Paket schon einmal eingetroffen ist. Hierzu wird, falls diese Option im Empfnger aktiviert ist, der Sequenzzhler im ESP-Header ausgewertet und nachgeschaut, ob sich der Zhlerwert im Empfangsfenster befindet. Falls das Paket einmalig ist, wird der HMAC des Pakets vom Empfnger berechnet und mit dem Wert im Paket verglichen. Sind beide gleich, so wurde das Paket nicht verndert und ist authentisch. Nachdem also festgestellt worden ist, dass das Paket zum ersten Mal eingetroffen, integer und authentisch ist, kann es der rechenintensiven Entschlsselung zugefhrt werden. Sobald das Paket entschlsselt ist, wird aufgrund des NextHeader-Feldes geprft, wie das Paket weiterverarbeitet werden soll. Ist in dem Feld eine 4 eingetragen, handelt es sich um ein Paket im Tunnelmodus, und das eingekapselte Paket wird entpackt und der nchsthheren Verarbeitungsschicht zugefhrt. Steht in diesem Feld ein anderer Wert, wird das vorliegende Paket sofort zur entsprechenden Verarbeitungsschicht weitergeleitet.
7.9
IPSec-Implementierungen
Die IPSec-Funktionalitt kann auf verschiedene Arten implementiert werden. Dies hngt von einigen Faktoren ab, zum Beispiel davon, ob gemischte, also IP- und IPSec-Funktionalitt auf dem gleichen Interface notwendig ist oder nicht.
7.9.1
Betriebssystemebene, IPSec-Stack
In dieser Variante wird der ursprngliche IP-Stack durch einen neuen Stack ersetzt, der eine zustzliche IPSec-Funktionalitt aufweist. Dies ist eine leistungsfhige Implementierung, die allerdings nur in bestimmten Systemumgebungen einsetzbar ist, z.B. in Routern oder dedizierten VPN-Gateways. Falls es sich bei dem Gateway um ein reines VPN-System handelt, kann man auch ganz spezielle, gehrtete Stacks einsetzen, die zustzliche Sicherheit bieten knnen. Diese Implementierungen verarbeiten ausschlielich diejenigen Protokolle, die fr ihre Funktionalitt bentigt werden. Ein spezieller IPSecStack wrde zum Beispiel alle Pakete auer Protokoll 17 mit Portnummer 500 (IKE), Protokoll 50 (ESP) und Protokoll 51 (AH) ohne weitere Aktivitten verwerfen (silent discard) und wre dadurch vor einer ganzen Reihe von Denialof-Service-Angriffen sicher.
214
Betrachtungen zur IPSec-Performance
Applikationsschichten
Applikationsschichten TCP
IPSec
Datenbertragungsschicht
TCP
IP
UDP
UDP
IPSec
Datenbertragungsschicht
IPSec hat die IP-Schicht ersetzt
IPSec als zustzliche Schicht zwischen IP- und Datenbertragungsschicht
Abbildung 7.12: Die verschiedenen Arten einer IPSec-Implementierung
7.9.2
Bump-in-the-Stack (BITS)
Insbesondere fr PC-Implementierungen, in denen die IPSec-Funktionalitt nicht vom Hersteller des Betriebssystems eingebaut ist, muss man eine andere Implementierung whlen. Denn anderenfalls wrde man massiv in die Netzwerkfunktionalitt eingreifen, und bei jedem Update des Betriebssystems wrde IPSec wieder vom herstellereigenen IP-Stack ersetzt werden. Als Lsung fgt man IPSec als zustzliche Verarbeitungsschicht zwischen IPEbene und Datenbertragungsschicht ein. Hier wird zwar die Netzwerkschicht zweimal durchlaufen, was nicht der leistungsfhigste Ansatz ist, aber dafr ist diese Methode sehr flexibel und sowohl vom IP-Stack als auch von der bertragungstechnologie fast unabhngig.
7.10 Betrachtungen zur IPSec-Performance

ber die so genannte Performance von IPSec ist in der letzten Zeit ein derart groer man muss es leider wirklich so drastisch formulieren Unsinn verffentlicht worden, dass diesem Thema hier ein eigener Abschnitt gewidmet ist. Mit dem Begriff Performance von IPSec fangen die Missverstndnisse bereits an, denn IPSec ist eine Protokolldefinition; IPSec weist daher weder einen bestimmten Datendurchsatz auf, noch kennt es Verzgerungszeiten. Auch Aussagen wie die, dass man sich, anstatt IPSec einzusetzen, Gedanken ber eine Hardwareverschlsselung machen sollte, sind barer Unsinn, da sich IPSec und Hardwareverschlsselung nicht ausschlieen im Gegenteil: Eine ganze Reihe von Herstellern setzt Hardwarebausteine zur Verschlsselung von IPSec ein. Es wurden wohl, aus welchen Grnden auch immer, nicht gut
215
gelungene Implementierungen von IPSec dazu benutzt, das Protokoll als solches als schlecht einzustufen ein unzulssiger Vorgang, wie Sie im Folgenden auch sehen werden. Ich mchte an dieser Stelle versuchen, einmal pragmatisch an das Thema heranzugehen, und zeigen, was die Performance von IPSec-Implementierungen tatschlich beeinflusst und welchen praktischen Effekt dies haben kann. Ich habe mit Bedacht, obwohl die technische Durchfhrung kein Problem gewesen wre, auf Messungen verzichtet, da ich am Sinn bestimmter Messungen erhebliche Zweifel hege und wirklich ganz selten einen Messaufbau gesehen habe, der mit einer echten Netzwerkumgebung mit all ihren verschiedenen Applikationen, Protokollen und fehlkonfigurierten Komponenten auch nur annhernd vergleichbar wre. Die meisten Messungen, die verffentlicht werden, stammen von Herstellern, unabhngigen Reports (die Anfhrungszeichen stehen hier fr eine Einschrnkung, denn nicht wenige solcher Vergleichstests werden von einem der Testkandidaten finanziert der dann auch prompt gewinnt) oder Fachzeitschriften. Letztere sind oft der rettende Strohhalm, denn diese haben zumindest die Mglichkeit, wirklich unabhngig zu testen oder testen zu lassen. Aber letztendlich sind Labor-Messungen niemals identisch mit dem Verhalten der Systeme in der realen Welt unserer heutigen Sprach- und Datennetze. Die Performance von IPSec-Implementierungen hngt von einer Reihe von Faktoren ab. Zuerst einmal legt die Security Policy selbst den Aufwand fest, den eine IPSec-Implementierung treiben muss, um die notwendigen Transformationen durchzufhren. Es ist offensichtlich, dass AH mit HMAC-MD5-96 im Transportmodus weitaus weniger Verarbeitungsressourcen bentigt, als ESP mit Triple-DES und HMAC-SHA1-96 im Tunnelmodus um gleich einmal zwei Extremflle zu betrachten. Zum anderen sind natrlich die Ressourcen des Systems, auf dem IPSec implementiert ist, dafr entscheidend, ob eine ausreichende Leistung zur Verfgung steht. Ein anderer Faktor ist die zustzliche Paketgre, die von IPSec erzeugt wird. Auch hier ist der Extremfaktor wieder der ESP-Tunnelmodus mit Authentifizierung und Verschlsselung. Der Overhead fllt hier umso mehr ins Gewicht, je kleiner die Nutzlastpakete sind. Damit wird zunehmend die Nutzbandbreite verkleinert, und eine Steigerung der bertragungskosten ist die Folge. Das IKE-Protokoll kann fr eine IPSec-Sicherheitsassoziation auch eine Datenkomprimierung aushandeln, falls beide Gegenstellen dies untersttzen. Dies ist auch sehr wichtig, da zum einen die Pakete kleiner werden und zum anderen verschlsselte Pakete nicht mehr komprimierbar sind. Verschlsselungsverfahren erzeugen nmlich ein Bitmuster, in dem praktisch keine sich wiederholenden Muster mehr vorkommen. Darauf bauen allerdings die Komprimierungsverfahren auf. Die gut gemeinte Idee, auf tieferen Schichten,
216
Betrachtungen zur IPSec-Performance
z.B. auf PPP-Ebene, eine Datenkomprimierung zu aktivieren, bringt gar nichts, auer der Verschwendung von Rechenleistung und Speicherplatz und, je nach eingesetztem Verfahren, sogar zustzlicher Paketlnge. Also sollte die IPSec-Komprimierung aktiviert werden, wodurch die Daten vor der Verschlsselung komprimiert werden. Allerdings sollte man sich in diesem Fall vor Augen halten, dass dies auch wieder ressourcen-intensiv ist und die Gesamtleistung des Systems nachteilig beeinflussen kann. Zusammenfassend kann man sagen, dass heutige moderne Rechner mit ausreichend Arbeitsspeicher und hinreichend leistungsfhigen CPUs der Pentium-Klasse mit IPSec-Clients keine Probleme haben. Manche Hersteller lassen sogar bei der Installation ihrer Clientsoftware eine Testroutine ablaufen, die testet, ob es sich um ltere CPUs handelt, und die Installation dann nicht mehr zulsst. Bei IPSec-Gateways oder VPN-Remote-Access-Konzentratoren auf IPSecBasis hngt es sehr stark vom Design des Systems ab, wie hoch seine Leistungsfhigkeit ist. Allgemein kann man sagen, dass ein speziell fr Tunneling und IPSec entwickeltes System ohne spezielle Hardwarebeschleuniger durchaus Leistungen im Bereich von 40 bis 50 Mbit/s bei mehreren tausend SAs mit Triple-DES-Verschlsselung bieten kann. Viele Systeme bieten die Option, Hardwarebeschleuniger einzubauen, um die Leistung weiter zu erhhen. Bei der Auswahl solcher Karten ist allerdings Vorsicht geboten. Einige Karten bieten nur eine extrem limitierte Funktionalitt. Manche Boards verarbeiten nur einen einzigen Verschlsselungsalgorithmus, z.B. Triple-DES, andere Verfahren wie DES, MD5, SHA1, und vor allem die IPSec-Komprimierung erfolgt weiterhin in Software. Viel besser stehen solche Boards da, die die komplette Palette von IPSec-Transformationen in Hardware realisiert haben und damit das Muttersystem ganz entscheidend entlasten. Manche Chipstze untersttzen sogar Public-Key-Verfahren wie RSA und Diffie-Hellman und bringen somit auch einen ernormen Leistungsschub in das extrem rechenintensive IKE-Protokoll. Auf eine solche Funktionalitt ist ganz besonders dann Wert zu legen, wenn in einem kurzen Zeitraum eine groe Anzahl von Sicherheitsassoziationen aufgebaut werden und eine Authentifizierung auf Basis von digitalen Signaturen und Zertifikaten erfolgt. Dies ist blicherweise bei Remote-Access-VPNs der Fall, wenn sich zu bestimmten Stozeiten sehr viele Benutzer anmelden. Bei Hardwarebeschleunigern muss man zwei Anstze unterscheiden: Einmal spezielle Erweiterungsboards, die mit speziellen Krypto-Chips ausgestattet sind, in denen die Algorithmen tatschlich per Hardware abgebildet sind, sowie andere Boards, die mit so genannten General-Purpose-Prozessoren ausgestattet sind, die lediglich die System-CPU entlasten und keine spezielle Logik zum Verarbeiten von kryptologischen Verfahren implementiert haben.
217
Spezielle Chips, wie der 7901 der Firma Hi/fn, haben zum Beispiel die ganze Logik von DES, Triple-DES, SHA-1, MD5 und LZS-Kompression in Hardware realisiert und ermglichen dabei Durchstze von IPSec-ESP (Triple-DES, HMAC-SHA1 und Datenkomprimierung, also Worst-case-Bedingungen) von 37 Mbit/s. Der Chip untersttzt auch Public-Key-Verfahren, allerdings nicht mit einem speziellen Maskendesign, sondern nur mit einer normalen CPU. Somit sind auch nur 6 IKE-Verbindungen pro Sekunde mit Pre-SharedKey-Authentifizierung mglich und nur 1,5 Verbindungen, falls man digitale Signaturen benutzt. Mehr zur Beschleunigung von Public-Key-Algorithmen im IKE-Protokoll erfahren Sie im nchsten Kapitel. Ein anderes Qualittskriterium fr IPSec, speziell bei Sprach- oder interaktiven Videoanwendungen, ist die Verzgerungszeit (Delay) der Pakete. Hier gibt es bestimmte Grenzen, die nicht berschritten werden drfen. Beispielsweise sollte bei Sprachanwendungen die Paketlaufzeit unter 200 ms liegen. Hier zuerst die schlechte Nachricht: Eine Echtzeitanwendung fr bestimmte Maschinensteuerungen, die eine Verzgerung von einer Millisekunde (1/1000 Sekunde) gegenber unverschlsseltem IP nicht mehr toleriert, ist fr manche IPSec-Implementierungen ein Problem. Die gute Nachricht ist die, dass man in solchen Umgebungen ohnehin selten IPSec einsetzt und alle sonstigen Daten-, Sprach- und Videoapplikationen mit Verzgerungen im Bereich einiger Millisekunden berhaupt keine Probleme haben. Kleine und mittlere Access-Router, die eigentlich nie fr IPSec entwickelt wurden, weisen in der Regel Paketlaufzeiten von 1 ms bis 3 ms auf. Einer der besagten Tester hatte sich darber erbost, dass die Paketlaufzeit durch IPSec um etwa 150% erhht wurde. 150%! Das wren ja unglaubliche 2,5 ms bis 7,5 ms Verzgerungszeit. Wenn ich nur den Wert 7,5 ms als Paketlaufzeit kennen wrde, wrde ich sagen: Okay, klingt ja nicht schlecht, kein Problem fr Sprache, Daten und Video. Diese Grenordnung relativiert sich endgltig, wenn man sich einerseits ins Gedchtnis zurckruft, welche Laufzeiten in gnstigen Fllen im Internet auftreten (im Mittel 30 bis 200 ms), und andererseits bercksichtigt, dass dieser Wert in einem echten VPN-System deutlich niedriger, in der Regel unter 1 ms, sein wird. Zusammenfassend ist zu sagen, dass gute Implementierungen von IPSec, sowohl im traditionellen Daten- als auch im Sprach- und Videoumfeld eingesetzt werden knnen. Der Durchsatz ist sehr gut, und die Verzgerungen sind sehr klein, in jedem Fall aber um Grenordnungen kleiner als die durch die Router produzierten Delays. Man darf sich nicht durch einige wenige schwarze Schafe und IPSec-Implementierungen auf Standardroutern, die niemals fr Verschlsselungssoftware ausgelegt wurden, tuschen lassen. Ein gutes, auf Verschlsselung und Tunneling optimiertes VPN-System, und
218
Zuknftige Entwicklungen
davon gibt es mittlerweile einige, lsst in Bezug auf Performance heute keine Wnsche mehr offen und wem das immer noch nicht ausreicht, der kann in vielen Systemen Hardwarebeschleuniger nachrsten.
7.11 Zuknftige Entwicklungen

Die Zukunft von IPSec kann man in Augenblick ruhigen Gewissens als rosig bezeichnen. Dies hat zwei Grnde. Zum einen gibt es momentan kein ernst zu nehmendes, konkurrierendes Protokoll, und andererseits ist IPSec im IP-Protokoll der Zukunft, IP Version 6, bereits integriert. Genau genommen wurde es ja von diesem neuen Protokoll auf das alte IP portiert. Die Industrie tut ihr Eigenes dazu, indem IPSec in die Betriebssysteme und das Netzwerkequipment fast aller Hersteller Einzug gehalten hat. Da das NIST mittlerweile mit Rijndael den Nachfolgealgorithmus von DES ausgewhlt hat (vgl. Kapitel 4), ist es absehbar, dass dieses Verfahren in Zukunft in IPSec obligatorisch oder wenigstens empfehlenswert werden wird, insbesondere da es frei von Lizenzgebhren ist. Allerdings ist IP Security lngst nicht berall einsetzbar. Insbesondere im Bereich von IP-Multicasting muss man vorerst darauf verzichten. Dies hngt damit zusammen, dass IPSec von seiner Struktur her ein reines Punkt-zuPunkt-Protokoll ist. Beim Multicast kommuniziert ein IP-System jedoch mit einer Gruppe von IP-Systemen, die unter einer so genannten Multicastadresse erreichbar sind. Hier kann man weder IPSec noch IKE einsetzen. Eine der wichtigsten Entwicklungen im IPSec-Umfeld sind daher die Aktivitten im Bereich der Multicasting-Arbeitsgruppe der Internet Engineering Task Force. Hier ist allerdings noch einiges an Entwicklungsarbeit notwendig, bis man zu brauchbaren Lsungsvorschlgen kommen wird. Weiterhin in Arbeit sind Standards fr DHCP, die Konfiguration von IPSec, die Erkennung von toten Gegenstellen und weitere Verbesserungen und Erweiterungen der IPSec-Protokollfamilie.
219
8
8.1
Das Internet-KeyExchange-Protokoll
Im vorangegangenen Kapitel zum Thema IP Security wurde davon ausgegangen, dass die fr die verschiedenen kryptographischen Algorithmen bentigten Schlssel bereits dort sind, wo sie bentigt werden. Beide Gegenstellen einer IPSec-Sicherheitsassoziation teilen sich einen gleichen, symmetrischen Schlssel, mit dem eine Seite verund die andere Seite wieder entschlsseln kann. In Kapitel 4, Sicherheitstechnologie, wurde auerdem erwhnt, dass die Lebensdauer der Schlssel nicht zu hoch sein soll, sie also regelmig erneuert werden sollen.
Das Henne-Ei-Problem
Jetzt fragt man sich natrlich, wie das im Netzwerkumfeld zu bewerkstelligen ist, wenn beide Partner einer Sicherheitsassoziation (SA) ber ein physikalisches Medium, nennen wir es im Weiteren einfach Leitung, miteinander verbunden sind. ber diese Leitung kann man die Schlssel nicht austauschen, denn sie ist ja nicht gesichert, da noch keine Schlssel auf beiden Seiten vorliegen. Diese mssen erst ausgetauscht werden. Das typische Henne-EiProblem: Was war zuerst da? Ein Ausweg, der lange Zeit der einzige war, bestand darin, die Schlssel ber ein anderes, sicheres Medium zu den Gegenstellen zu transportieren. Die manuelle Schlsselverteilung, also der Transport des oder der Schlssel auf Papier oder Datentrger und die manuelle Hinterlegung auf den Sicherheitssystemen, ist ein Beispiel hierfr. Diese Verfahren haben jedoch alle einen Nachteil: Sie erhhen meist die Komplexitt und damit auch meist die Fehleranflligkeit und in der Folge die Unsicherheit des gesamten Systems. Lange Zeit wurde nach einem anderen Weg gesucht, von dem man sich aber nie so recht vorstellen konnte, wie er funktionieren wrde. Dieser andere, neue Weg zur Schlsselverteilung ist erst seit Mitte der 70er Jahre bekannt, seit Whitfield Diffie und Martin Hellman mit ihrer die Kryptographie revolutionierenden Arbeit eine Lsung des Schlsseltausch-Problems prsentierten (vgl. Kapitel 4), die auch nach ihnen benannt wurde. Das DiffieHellman-Verfahren ist ein auf Methoden der Public-Key-Kryptographie beruhender Algorithmus zum sicheren Erzeugen von Schlsseln durch die bertragung bestimmter Informationen ber ein unsicheres Medium. Auf Basis dieses Verfahrens wurde eine Reihe von Schlsseltauschprotokollen entwickelt, die zum Teil auch die Grundlage des Internet-Key-Exchange-Protokolls (IKE) bilden, das zum Erzeugen einer IPSec-Sicherheitsassoziation eingesetzt wird.
221
8 Das Internet-Key-Exchange-Protokoll
Das IKE-Protokoll ist eine Instanziierung von ISAKMP, dem Internet Security Association and Key Management Protocol und benutzt Austauschschritte, die im Oakley-Protokoll spezifiziert werden. IKE ist kein auf IPSec festgelegtes Protokoll, sondern wird durch Spezifikationen in der IPSec Domain of Interpretation (IPSec-DOI) im RFC2407 fr den Einsatz mit IP Security mit entsprechenden Datenstrukturen, Konstanten und Funktionen versehen. Andere DOIs knnen IKE auch fr andere Protokolle nutzbar machen, die einen sicheren Schlsseltausch bentigen. IKE benutzt, ebenso wie IPSec, das Konzept der Sicherheitsassoziationen (SA), die sich allerdings von den IPSec-SAs unterscheiden, unter anderem, da sie bidirektional sind und zwischen Initiator und Responder unterscheiden, je nachdem von welcher Seite IKE gestartet wurde. IKE kann in den verschiedensten Modi und Kombinationen mit etlichen Authentifizierungsverfahren arbeiten, es kann mehrere SAs fr IPSec in einem Austausch erzeugen und kann verschiedene Sicherheitsstufen implementieren. Diese Flexibilitt von IKE macht das Protokoll allerdings auch sehr komplex und langwierig zu implementieren. IKE, oder besser gesagt dessen praktische Implementierung, ist auch sehr oft der Auslser, wenn IPSec-Systeme unterschiedlicher Hersteller keine Sicherheitsassoziation miteinander erzeugen knnen. Aus diesem Grund ist dieses Kapitel sehr ausfhrlich angelegt, um Ihnen die Mglichkeit zu geben, bei Problemen die Meldungen der Logfiles richtig zu interpretieren und die notwendigen Manahmen einzuleiten. Auerdem ist das IKE-Protokoll uerst sicherheitskritisch, denn von ihm hngen alle spter eingesetzten Dienste und die von diesen verwendeten Schlssel ab.
8.2
ISAKMP
Das Internet Security Asscociation and Key Management Protocol ist ein Regelwerk, das das Verhalten der beteiligten Gegenstellen in den verschiedenen Phasen der Verbindungsverhandlung festlegt. Es legt die Paketformate der auszutauschenden Pakete fest, definiert bestimmte Funktionen und legt die bergnge zwischen den verschiedenen Zustnden einer ISAKMP-Aushandlung fest. Aber es legt nicht fest, wie dies zu geschehen hat, und ist daher auch nicht unmittelbar in Form eines Protokolls zu implementieren. Dies bleibt den Dokumenten zu IKE, Oakley und der IPSec-DOI vorbehalten. Im Internet Security Asscociation and Key Management Protocol werden verschiedene Austauschvorgnge beschrieben, innerhalb derer der Initiator einer Verbindung mit dem Responder bestimmte Nachrichten austauscht. Anzahl, Art und zeitliche Abfolge der Nachrichten sowie die bentigten Informationen in diesen Paketen hngen von der Art des Austauschvorgangs ab.
222
ISAKMP
ISAKMP ist nicht an bestimmte kryptographische Protokolle oder Algorithmen gebunden, ebensowenig an IPSec oder bestimmte Schlsseltauschprotokolle. Es bietet vielmehr eine flexible Mglichkeit, Sicherheitsassoziationen aufzubauen, und erlaubt es, die verschiedensten Techniken dafr einzusetzen. Damit bekommt man auch eine elegante Mglichkeit geboten, im Zuge der technologischen Entwicklungen neue Verschlsselungsverfahren oder Schlsseltauschprotokolle zu implementieren, ohne das zugrunde liegende Protokoll verndern zu mssen. Das Internet Security Asscociation and Key Management Protocol bietet innerhalb seiner Funktion zur Erzeugung von Sicherheitsassoziationen fr ISAKMP und IPSec auch Schutz vor einer ganzen Reihe von Angriffen, insbesondere vor Denial-of-Service-Angriffen, dem Stehlen von Verbindungen und Man-in-the-Middle-Angriffen. ISAKMP spezifiziert Nachrichten, die zwischen Initiator und Responder ausgetauscht werden, und legt ihre Formate fest. Diese Nachrichten werden in heute blichen Implementierungen in UDP-Pakete mit der Quell- und Zielportnummer 500 eingepackt. Es sind zwar optional auch weitere Kombinationen von Protokoll- und Portnummern mglich, jedoch mssen alle Implementierungen den UDP-Port 500 untersttzen. ISAKMP regelt die Erzeugung von Austauschvorgngen und den dafr bentigten Nachrichten zum Erzeugen, Konfigurieren und Lschen von Sicherheitsassoziationen. Weiterhin wird der Austausch von Werten beschrieben, die von den Schlsseltausch-protokollen bentigt werden. Diese Protokolle selbst sind aber nicht Gegenstand von ISAKMP, sondern sie benutzen nur dessen Nachrichten. Es werden fnf verschiedene Arten von Austauschvorgngen definiert, die verschiedene Ziele verfolgen und unterschiedlich starke Schutzmechanismen implementiert haben. Darin ist innerhalb eines gewissen Rahmens przise festgelegt, in welcher Abfolge die Nachrichten zu bertragen sind, wie sie verarbeitet werden mssen, welche Art von Nutzdaten enthalten sein sollen und welche optional sind. Die Sicherheitsstrategie von IKE und IPSec hat ebenfalls noch einen Einfluss auf das Verhalten eines Austauschvorgangs, speziell darauf, wann er aufgrund bestimmter kritisch erscheinender Zustnde abzubrechen ist.
8.2.1
Die Sicherheit von ISAKMP
ISAKMP ist aufgrund der Tatsache, dass es eine Sicherheitsassoziation fr Sicherheitsprotokolle wie IP Security aushandelt, natrlich als uerst sicherheitskritisch anzusehen. Denn falls sich in dieser Phase bereits Ansatzpunkte fr Angriffe bieten, sind die nachfolgenden Sicherheitsassoziationen auch betroffen. Denn selbst der sicherste Verschlsselungsalgorithmus ist wirkungslos, wenn sein Schlssel bekannt ist.
223
Aus diesem Grund wurde eine ganze Reihe von Schutzmechanismen fr das Internet Security Asscociation and Key Management Protocol festgelegt. Diese sind aber nicht mit dem zu verwechseln, was ISAKMP fr die folgenden Sicherheitsassoziationen der Sicherheitsprotokolle aushandelt. Authentifizierung Ein ganz wesentlicher Punkt in diesem Zusammenhang ist die gegenseitige Authentifizierung der beiden Gegenstellen. Hier muss man sich aber noch einmal vor Augen halten, dass es sich hierbei keinesfalls um eine BenutzerAuthentifizierung handelt, sondern um eine gegenseitige Identifikation auf der Netzwerkebene. Diese kann zwar mit einer Benutzer-Authentifizierung kombiniert werden, falls es sich bei einer Gegenstelle um einen Host handelt, dessen spezifische Informationen zur Identifikation des Systems vom Benutzer selbst stammen, beispielsweise ein Passwort (Pre-Shared Secret) oder ein digitales Zertifikat der betreffenden Person. Aber im Kontext von ISAKMP bzw. IKE, das, wie im Folgenden beschrieben, dessen Austauschvorgnge benutzt, werden wir von einer Authentifizierung der Endsysteme ausgehen und uns nicht damit beschftigen, wie die notwendigen, geheimen Informationen zum Nachweis der Identitt zur Verfgung gestellt wurden. Als Mechanismen zur Authentifizierung dienen im Wesentlichen Methoden, die auf Basis von Einwegfunktionen Zufallszahlen in Verbindung mit geheimen Informationen zur Identitt der betreffenden Gegenstelle in einen Wert transformieren, der ber ein unsicheres Medium zur Gegenstelle bertragen werden kann. Die Gegenstelle berechnet ebenfalls diesen Wert und vergleicht beide. Im Fall einer bereinstimmung ist die Gegenseite authentisch. Als Funktion wird in der Regel die Hashfunktion eingesetzt, die in den ersten Nachrichten innerhalb eines Austauschvorgangs vereinbart wurde. Da diesen Verfahren je nach Qualitt ihrer Implementierung nur eine begrenzte Sicherheit bescheinigt wird, werden von der Sicherheitsgruppe der Internet Engineering Task Force (IETF) solche Verfahren bevorzugt, die auf digitalen Signaturen unter Verwendung von Public-Key-Algorithmen (vgl. Kapitel 4) und digitalen Zertifikaten (vgl. Kapitel 5) basieren. Allerdings wird dadurch eine erhebliche zustzliche Komplexitt eingefhrt, die durch die erforderliche Verwaltung der ffentlichen Schlssel oder Zertifikate bedingt ist. In vielen Organisationen ist die dazu notwendige Infrastruktur in Form von Schlsselverwaltungssystemen oder Verzeichnisdiensten noch nicht oder nicht in ausreichendem Mae implementiert. Als Folge davon sieht die Realitt der Authentifizierung im IP-Security- und ISAKMP-Umfeld grtenteils so aus, dass sie nach wie vor auf so genannten Pre-Shared Keys, also de facto einem Passwort in Verbindung mit einem Hashverfahren, beruht. Nichtsdestotrotz fordert der Standard zwingend, dass auch eine starke Authentifizierung implementiert werden muss. Hierzu wird die Benutzung eines Algorith-
224
ISAKMP
mus zur Erzeugung von digitalen Signaturen vorgeschrieben. Dieser ist zwar nicht spezifiziert, jedoch findet man in fast allen Implementierungen das RSA-Verfahren, dessen Patentschutz mittlerweile abgelaufen ist, oder den Digitalen Signaturstandard (DSS) vor. Aber man kann, insbesondere bei IPSec-Gateways, auch die Authentifizierung per Pre-Shared Key relativ sicher machen. Denn hier kann man entsprechend lange und nicht per Wrterbuchangriff zu erratende hexadezimale Zahlen eingeben. In IPSec-Hostimplementierungen, in denen der Pre-Shared Key ein Kennwort ist, das der Benutzer im Gedchtnis zu behalten muss, ist dies nicht mglich, hier bieten sich alle bekannten Mglichkeiten von Angriffen auf Passwrter. An dieser Stelle sei auch ein wichtiger Sicherheitstipp angebracht: Viele IPSecHostimplementierungen bieten optional eine starke Authentifizierung auf Basis von Token-Karten mit Einmalcodes an. Diese hat aber keinen Einfluss auf die Authentifizierung in ISAKMP, IPSec-ESP oder IPSec-AH! Denn diese Form des Identittsnachweises eines Benutzers erfolgt in vernnftigen Implementierungen unter dem Schutz einer bereits etablierten Sicherheitsassoziation, die vorher auf Basis von Pre-Shared Keys erzeugt wurde. Nachfolgende SAs benutzen ohnehin Werte, die auf dem Schlsseltausch basieren. Also authentifizieren, wie gesagt, solche Systeme ausschlielich den Benutzer. Die einzige Schnittstelle zu IKE besteht darin, dass bei einer fehlgeschlagenen Authentifizierung die Sicherheitsassoziation gelscht und IKE terminiert wird. Kryptographie und die Sicherheit des Schlsseltauschs Die Kryptographie ist die Sttze des Internet Security Asscociation and Key Management Protocol, denn sehr viele seiner Funktionen basieren auf den Entwicklungen und Technologien dieser Wissenschaft. Insbesondere die Erzeugung von symmetrischen Schlsseln zur Verwendung mit Verschlsselungsverfahren oder Algorithmen zur Integrittsprfung und Authentifizierung basiert auf der Public-Key-Kryptographie. Mit der Public-Key-Kryptographie bieten sich zwei verschiedene Mglichkeiten des Schlsseltauschs an: Man kann den Schlssel selbst mit einem Algorithmus wie dem RSA-Verfahren verschlsseln und zur Gegenstelle bertragen, oder man kann mit einem speziellen Verfahren, wie dem von DiffieHellman, den Schlssel auf beiden Seiten erzeugen. Man kann also zwischen der Schlsselbertragung und der Schlsselerzeugung whlen. Im ISAKMPStandard wird, zugegebenermaen etwas schwammig formuliert, lediglich ein authentifizierter Schlsseltausch vorgeschrieben. IKE schlgt die Methode der Schlsselerzeugung per Oakley-Protokoll mit dem Diffie-Hellman-Verfahren vor, und praktisch alle Implementierungen richten sich auch danach.
225
Die Authentifizierung des Schlsseltauschs in ISAKMP ist unabdingbar, denn Public-Key-Algorithmen wie RSA oder Diffie-Hellman selbst bieten keinerlei Schutz gegen so genannte Man-in-the-Midle-Angriffe, bei denen sich ein Angreifer in die Kommunikation einschaltet und den beiden Gegenstellen jeweils die andere vorspiegelt. Die Authentifizierung kann direkt whrend des Schlsseltauschs oder unmittelbar danach erfolgen, sollte aber zum Schutz vor Denial-of-Service-Angriffen rechenintensiven Funktionen stets vorangestellt sein. Die Behandlung von Schlsseln innerhalb von Netzwerk-Sicherheitsprotokollen wie IKE und IP Security unterscheidet sich in einem entscheidenden Punkt von anderen Anwendungen. Whrend verschlsselte Daten verschiedener Applikationen teilweise Jahre oder Jahrzehnte geheim bleiben mssen und nach oder innerhalb dieser Zeitspanne zur weiteren Verwendung entschlsselt werden mssen, liegen im Netzwerkbereich ganz andere Voraussetzungen vor. Die Schlssel werden dort nur solange bentigt, bis das letzte bertragene Paket innerhalb der Lebensdauer einer Sicherheitsassoziation vom Empfnger entschlsselt wurde. Dann kann oder um es ganz deutlich zu sagen muss der Schlssel zuverlssig vernichtet werden, denn er wird definitiv nicht mehr bentigt. Als noch kritischer ist die Behandlung der privaten Komponenten eines Schlsseltauschverfahrens wie Diffie-Hellman einzustufen. Denn hier wird der private, auf zuflliger Basis erzeugte Schlssel nur so lange bentigt, bis beide Seiten daraus ihren symmetrischen Hauptschlssel berechnet haben. Die erforderliche Lebensdauer liegt somit maximal im einstelligen Sekundenbereich. Eine lngere Speicherung birgt ein erhebliches Sicherheitsrisiko, da nur ein einziger bekannt gewordener privater Schlssel auf einer der beiden Seiten einer Sicherheitsassoziation die komplette Kommunikation kompromittiert, d.h. dass Vertraulichkeit, Integritt und Authentizitt der bertragenen Pakete nicht mehr gewhrleistet sind. Aus diesem Grund muss die private Diffie-Hellman-Komponente sofort nach der Erzeugung des symmetrischen Schlssels sicher vernichtet werden. In der Regel erfolgt dies durch mehrfaches berschreiben und die anschlieende Freigabe des vom Algorithmus benutzten Speicherbereichs. Schutz vor Denial-of-Service-Angriffen Die schlechte Nachricht zuerst: Ein absoluter Schutz gegen Denial-of-ServiceAngriffe ist in keinem bertragungssystem mglich. Das einfache Fluten von ffentlichen Schnittstellen mit Datenpaketen ist immer eine, wenn auch brachiale und mittlerweile meist mit einer empfindlichen Strafe fr den Angreifer endende Mglichkeit.
226
ISAKMP
Die gute Nachricht ist die, dass es gegen die subtileren Angriffe eine ganze Reihe brauchbarer Schutzmechanismen gibt. In ISAKMP basiert der Schutz auf so genannten Anti-Clogging-Tokens (ACT), schlicht Cookies genannt. Mit Hilfe dieser Technik kann man wirkungsvoll verhindern, dass ein Angreifer mit geflschten IP-Absenderadressen an einer ISAKMP-Aushandlung teilnimmt und die Gegenstellen zu ebenso umfangreichen wie sinnlosen Berechnungen und Operationen veranlasst. Schutz vor dem Stehlen von Verbindungen Ein Angreifer, der eine Verbindung stehlen will, indem er Vermittlungssysteme entsprechend manipuliert, um anstelle einer der beiden Gegenstellen weiter an ISAKMP-Aushandlungen teilzunehmen, wird dadurch abgeblockt, dass die Authentifizierung mit der Aushandlung der Sicherheitsassoziation und des Schlsselaustauschs verbunden ist. Schutz vor Man-in-the-Middle-Angriffen Ein Man-in-the-Middle-Angriff auf eine ISAKMP-Aushandlung wrde versuchen, bestimmte Nachrichten zu ndern oder zu lschen. In Abbildung 8.1 sehen Sie einen vereinfacht dargestellten Angriff auf die Aushandlung einer Sicherheitsassoziation in ISAKMP. Der Initiator mchte in diesem Beispiel mit dem Responder wahlweise das ESP-Protokoll ohne, mit DES- oder mit Triple-DESVerschlsselung vereinbaren. Er wrde, wie in Abbildung 8.1 oben gezeigt, eine Nachricht mit dem entsprechenden Vorschlag abschicken, und der Responder, dessen strenge Sicherheitsstrategie in unserem Fall nur eine starke Verschlsselung zulsst, wrde aus diesem Angebot den Vorschlag ESP-3-DES auswhlen. Der Angreifer, unser Man-in-the-Middle, schaltet sich nun in die Verbindung ein und versucht, dem Initiator den originalen Responder vorzutuschen und umgekehrt. Er manipuliert die Antwort des Responders dahin gehend, dass er aus dem Vorschlag des Initiators keine Verschlsselung (ESP-NULL) auswhlt, obwohl der Responder in Wirklichkeit 3-DES selektiert hat. Dann wrde der Initator im Weiteren mit dem Man-in-the-Middle unverschlsselt kommunizieren, der originale Responder wrde aber wie von ihm gefordert mit Triple-DES-Verschlsselung arbeiten. Beim Man-in-the-Middle selbst und auf der Strecke zwischen ihm und dem Initiator wren die Daten unverschlsselt und somit nicht mehr vertraulich. Die Gegenstellen selbst glauben aber jeweils, mit dem originalen Partner zu kommunizieren und sich auf eine beiderseitig akzeptable Protection Suite geeinigt zu haben. Gegen diese Art von Angriff richten sich gleich eine ganze Menge von Manahmen in ISAKMP. Zum einen sind das die bereits beschriebenen Manahmen gegen das Stehlen von Verbindungen sowie die Bindung der Austauschvorgnge an eine Authentifizierung. Die Erzeugung der Cookies basiert unter anderem auf der aktuellen Zeit, so dass hierdurch auch gleichzeitig ein Schutz
227
gegen wiederholtes Senden gewhrleistet wird. Andere Angriffe, z.B. auf spezielle Protokolle wie TCP, werden durch den Einsatz von UDP vermieden. Der sichere Transport von UDP-Paketen wird durch geeignete Manahmen im ISAKMP erreicht, so dass der Verzicht auf das verbindungsorientierte TCP keine Probleme mit sich bringt.
Initiator
Normale IKE-Aushandlung
Vorschlag: ESP-NULL oder ESP-DES oder ESP-3-DES
Responder
ESP-3-DES akzeptiert
3-DES-Verschlsselung
Man-in-the-Middle-Angriff
Initiator
Man-in-the-Middle
Responder

ESP-3-NULL akzeptiert

ESP-3-DES akzeptiert
Unverschlsselt !
3-DES-Verschlsselung
Abbildung 8.1: Ein Man-in-the-Middle-Angriff auf eine IKE-Aushandlung
8.2.2
Der ISAKMP-Header
In Abbildung 8.2 sehen Sie das Format des ISAKMP-Headers. Die Felder haben folgende Bedeutung: Initiator Cookie und Responder Cookie Die ersten 16 Byte dieses Headers werden von so genannten Cookies, je eines vom Initiator und eines vom Responder, belegt. Diese Cookies dienen vor allem zum Schutz vor Replay-Angriffen und Angriffen mit geflschten Absenderadressen. Gebildet werden diese Werte aufgrund von Informatio-
228
ISAKMP
nen, die nur dem Erzeuger bekannt sind, sowie einem Zeitstempel, die als Parameter fr eine geeignete Funktion dienen, um den Wert zu berechnen. Es gibt keine feste Vorschrift, jedoch wird empfohlen, eine schnelle Hashfunktion wie MD5 zu benutzen und einen Hashwert ber die IP-Adressen, die Portnummern, eine lokal erzeugte, geheime Zufallszahl, die aktuelle Zeit und das Datum zu bilden. Somit ist nmlich garantiert, dass Informationen in die Cookies mit eingehen, die auf spezifischen Eigenschaften der Gegenstelle und der Verbindung beruhen, aber durch den Einfluss der aktuellen Zeit innerhalb ihrer Abfolge garantiert unterschiedlich sind.
0 7 15 31
UDP Header Initiator Cookie
Responder Cookie Next Payload
Version
Exchange Type
Flags
Message ID Length
Nutzdaten
Abbildung 8.2: Der ISAKMP-Header folgt dem UDP-Header
Die beiden Cookies zusammen bilden innerhalb der Verbindung zwischen den beiden IP-Endsystemen einen eindeutigen, 128 Bit groen Wert und dienen zustzlich zu ihrer Sicherheitsfunktion auch als ISAKMP-Security-Parameter-Index (SPI). Next Payload Die Art der Informationen, die auf den ISAKMP-Header folgen, wird durch bestimmte vordefinierte Typennummern festgelegt. Folgende, im Weiteren nher beschriebene Nutzdaten sind spezifiziert: Keine Nutzdaten enthalten (None) Sicherheitsassoziation Proposal
229
Transform Key Exchange Identification Certificate Certificate Request Hash Signature Nonce Notification Delete Vendor ID Die Art der Informationen bestimmt auch deren Struktur und eventuell deren Lnge, sofern darin keine variabel langen Werte enthalten sind. Version (Major Version, Minor Version) Die Version des Protokolls wird in einem Haupt- und Nebenfeld festgelegt. Die Implementierungen sollten niemals Pakete verarbeiten, bei denen ein Feld oder beide Felder hhere Versionsnummern enthalten als sie selbst. Exchange Type Der Wert dieses Feldes legt fest, um welche Art von Austausch es sich bei diesem Paket handelt. Die Arten legen unter anderem implizit fest, wie viele Austauschoperationen durchgefhrt werden, welche Nutzdaten im Paket folgen, welche Zustandsnderungen nach diesen Operationen eintreten und was sie in Summe bewirken sollen. Folgende Exchange Types sind in ISAKMP definiert: None (Keine Operation) Base Exchange Identity Protection Exchange (daraus wird der IKE Main Mode abgeleitet) Authentication Only Exchange Aggressive Exchange Informational Exchange
230
ISAKMP
Flags Optionen, die die weitere Verarbeitung des ISAKMP-Pakets steuern. Folgende drei Optionen knnen im Augenblick aktiviert werden: E-Bit (Encryption-Bit) C-Bit (Commit-Bit) A-Bit (Authentication-Only-Bit) Das Encryption-Bit wird gesetzt, wenn angezeigt werden soll, dass die Daten, die auf den Header folgen, verschlsselt sind. Die Verschlsselung wurde mit dem Algorithmus durchgefhrt, der in der ISAKMP-Sicherheitsassoziation ausgehandelt wurde. Das Commit Flag dient zur Synchronisierung der Schlsselerzeugung. Man kann es benutzen, um zu verhindern, dass verschlsselte Daten eintreffen, bevor die Sicherheitsassoziation vollstndig aufgebaut wurde und beide Seiten bereit sind. Mit gesetztem A-Bit wird angezeigt, dass ein Informational Exchange mit Notify-Daten vorliegt das nicht verschlsselt ist, aber mit dem vereinbarten Authentifizierungsverfahren auf Integritt geprft werden muss. Message ID Eine Identifikationsnummer fr die vorliegende Nachricht. Sie wird auf Zufallsbasis erzeugt. Length Dieses Feld gibt die Lnge der vollstndigen Nachricht, also ISAKMP-Header plus Nutzdaten, in Byte an.
8.2.3
Der generische ISAKMP-Nutzdaten-Header
Auf den ISAKMP-Header folgen die Nutzdaten, die aus mehreren Instanzen bestehen knnen, die aufeinander folgen knnen. Die Nutzdaten bestehen aus Strukturen, die alle mit einem generischen Header beginnen.
0 7 15 31
Next Payload
Reserved
Payload Length
Abbildung 8.3: Der generische ISAKMP-Nutzdaten-Header
231
In diesem Header sind die fr alle Arten von Nutzdaten gltigen Informationen enthalten: Next Payload Dieses Feld zeigt an, ob nach der Nutzdatenstruktur noch eine weitere folgt und welcher Art sie ist. Ist dieses Feld 0, dann folgt nichts mehr nach. Der Typ der ersten Struktur wird im ISAKMP-Header festgelegt. Reserved Dieses Feld ist fr sptere Erweiterungen reserviert. Payload Length Die vollstndige Lnge der vorliegenden Nutzlast, inklusive Header.
8.3
ISAKMP-Nutzdaten
Dem generischen Header folgen die Datenstrukturen, in denen die Nutzlast, also der Inhalt der Nachricht, enthalten ist. Fr jeden der verschiedenen Nutzlasttypen gibt es ein spezielles Format zur Reprsentation der zu bertragenden Informationen.
8.3.1
Die Sicherheitsassoziation-Payload
Diese Datenstruktur wird benutzt, um Sicherheitsattribute auszuhandeln und festzulegen, in welcher Umgebung (DOI) die Aushandlung stattfindet. Abbildung 8.4 zeigt das Datenformat. Die Felder haben folgende Bedeutung: Domain of Interpretation (DOI) Dieser Wert gibt an, in welcher Umgebung die Aushandlung erfolgt. 0 bedeutet, dass eine ISAKMP-SA ausgehandelt wird, der Wert 1 steht fr IPSec. Situation Dieses Feld hngt von der jeweiligen DOI ab und beschreibt die Situation, in der die Aushandlung stattfindet.
0 7 15 31
Next Payload
Reserved
Payload Length
Domain of Interpretation (DOI) Situation
Abbildung 8.4: Die SA-Payload

232
ISAKMP-Nutzdaten
8.3.2
Die Proposal Payload
In dieser Struktur sind die Informationen enthalten, mit denen eine Sicherheitsassoziation zwischen Initiator und Responder ausgehandelt wird. Diese so genannten Proposals enthalten die Sicherheitsfunktionen, die benutzt werden sollen, um die notwendigen Dienste zur Verfgung zu stellen. In der Regel werden in einem Austausch mehrere Vorschlge gemacht, die logisch verknpft werden knnen. Die Felder haben folgende Bedeutung: Proposal Nr Die Nummer des aktuellen Vorschlags.
0 7 15 31
Next Payload Proposal Nr
Reserved
Protocol-ID
Payload Length SPI Size # Transforms
Security Parameter Index (SPI)
Abbildung 8.5: Die Proposal Payload
Protocol-ID Die Protokoll-ID der gewnschten Sicherheitsfunktionen. Diese Funktionen sind in der Regel ESP, AH usw. SPI Size Dieses Feld gibt die Lnge des folgenden Security Parameter Index (SPI) in Byte an. No of Transforms Anzahl der Vorschlge (Proposals), die gemacht werden. SPI Hier wird der SPI der sendenden Gegenstelle eingetragen.
8.3.3
Die Transform Payload
In der Transform Payload werden die Informationen zu den gewnschten Sicherheitsdiensten selbst hinterlegt. Es knnen mehrere Transformationen in einer Nachricht vorkommen, ihre Anzahl wird in der Proposal Payload angegeben.
233
15
31
Next Payload Transform Nr
Reserved
Transform-ID
Payload Length Reserved
Security Association Attributes
Abbildung 8.6: Das Format der Transform Payload
Transform Nr Die eindeutige Nummer der Transform Payload. Transform-ID Die in der DOI fr die entsprechenden Funktionen spezifizierten Konstanten werden in diesem Feld eingetragen. SA Attributes Hier sind die Attribute der Sicherheitsassoziation enthalten.
8.3.4
Key Exchange Payload
Diese Nachricht enthlt Informationen, die zur Erzeugung der Sitzungsschlssel bentigt werden. Das Key-Exchange-Data-Feld enthlt zum Beispiel die ffentlichen Werte eines Diffie-Hellman-Austauschs im Fall des IKE-Protokolls.
0 7 15 31
Next Payload
Reserved
Payload Length
Key Exchange Data
Abbildung 8.7: Die Key Exchange Payload
Das Format, in dem die Daten in diesem Feld eingetragen sind, hngt dabei von der DOI und dem ausgewhlten Schlsseltauschverfahren ab.
234
ISAKMP-Nutzdaten
8.3.5
Identification Payload
In dieser Datenstruktur sind Informationen zur Identitt der Gegenstelle enthalten. Diese werden benutzt, um den Partner zu identifizieren und mit diesen Informationen auch eine Authentifizierung durchfhren zu knnen.
0 7 15 31
Next Payload ID Type
Reserved
Payload Length
DOI Specific ID Data Identification Data
Abbildung 8.8: Die ID Payload
ID Type Dieser Wert legt fest, welcher Art die Informationen zur Identifikation sind. DOI Specific ID Data Hier stehen DOI-spezifische Identifizierungsdaten. Identification Data In diesem Feld sind die Identittsinformationen enthalten.
8.3.6
Certificate Payload
Diese Nutzlast dient dazu, digitale Zertifikate zu bertragen, falls diese zur Authentifizierung bentigt werden. Eine Certificate Payload muss zu jedem Zeitpunkt einer Aushandlung akzeptiert werden. Falls keine Directory Services zur Verfgung stehen, mit denen Zertifikate verteilt werden, sollten Zertifikate in den Exchanges bertragen werden.
0 7 15 31
Next Payload Encoding
Reserved
Payload Length
Certificate Data
Abbildung 8.9: Die Certificate Payload
235
Certificate Encoding Dieses Feld enthlt Informationen ber die Kodierung des Zertifikats oder ber die Art der Daten im nachfolgenden Feld. Folgende Kodierungen werden untersttzt: PKCS#7-kodiertes X.509-Zertifikat PGP-Zertifikat DNS-signierter Schlssel X.509-Zertifikat zur Signatur X.509-Zertifikat zum Schlsseltausch Kerberos Token Certificate Revocation List (CRL) Authority Revocation List (ARL) SPKI-Zertifikat X.509-Attribut-Zertifikat Certificate Data Hier befindet sich das eigentliche Zertifikat oder eine Information in einem der oben angefhrten Datenformate.
8.3.7
Certificate Request Payload
Dies ist eine Datenstruktur, die dazu benutzt wird, in einer ISAKMP-Nachricht von der Gegenstelle ein Zertifikat anzufordern. Sie ist nicht an bestimmte Nachrichten oder Zustnde von IKE gebunden und sollte dann verwendet werden, wenn den beteiligten Gegenstellen kein Verzeichnisdienst fr die Aufgaben der Zertifikatverteilung zur Verfgung steht. Der Empfnger einer Certificate Request Payload muss dem Sender sein Zertifikat zusenden.
0 7 15 31
Next Payload Cert. Type
Reserved
Payload Length
Certificate Authority
Abbildung 8.10: Das Format der Certificate Request Payload
236
ISAKMP-Nutzdaten
Certificate Type Der Typ des angeforderten Zertifikats wird in diesem Feld eingetragen. Es gelten die gleichen Typvereinbarungen wie in der Certificate Payload. Certificate Authority In diesem Bereich steht ein Wert, der die Certificate Authority identifiziert, die der Sender akzeptiert. In Fllen, in denen dies nicht notwendig ist, kann dieses Feld auch leer bleiben. Das Format des Eintrags ist meist der so genannte Distinguished Name der ausstellenden CA. Weitere Informationen zum Thema Zertifikate sind in Kapitel 5 nachzulesen.
8.3.8
Hash, Signature und Nonce Payload
Diese,von ihrer Struktur her identischen drei Datentypen bertragen entweder einen Hashwert, eine digitale Signatur oder einen Nonce. Hash Dieses Feld enthlt einen Hashwert, der aus der Hashfunktion gebildet wurde, die durch ISAKMP-Nachrichten zur Bildung der ISAKMP-Sicherheitsassoziation zwischen den beiden Gegenstellen vereinbart wurde. Die Lnge der Daten im Hash-Feld hngt vom verwendeten Algorithmus ab.
0 7 15 31
Next Payload
Reserved
Payload Length
Hash Data / Signature Data / Nonce Data
Abbildung 8.11: Die Hash-, Signature- oder Nonce Payload
Signature Im Falle einer Signature Paylaod ist der Wert im Datenfeld eine digitale Signatur, die von der Funktion erzeugt wurde, die bei der Aushandlung der ISAKMP-Sicherheitsassoziation vereinbart wurde. Die Lnge ist auch vom Signaturalgorithmus abhngig. Nonce Nonce ist ein Name fr einen Wert, der eine sehr starke Zufallskomponente enthlt. Er wird verwendet, um den Nachrichtenaustausch vor Angriffen durch wiederholtes Senden (Replay-Angriff) zu schtzen. Er wird meist in Schlsseltauschpaketen mit bertragen.
237
8.3.9
Notification Payload
Diese Datenstruktur wird verwendet, um darin Informationen zwischen zwei IKE-Gegenstellen auszutauschen. Dies knnen Mitteilungen ber bestimmte Fehlerzustnde sein, zum Beispiel darber, warum in einer Aushandlung ein Vorschlag zurckgewiesen wurde. Die Felder haben folgende Bedeutungen: Domain of Interpretation (DOI) Dieses Feld zeigt, in welcher Domain of Interpretation (ISAKMP oder IPSec) die Mitteilung erfolgt. Protocol-ID Hier steht die Protokollnummer des Protokolls, auf das sich die Mitteilung bezieht. Im Fall von IP Security knnen das ISKMP, IPSec-ESP und IPSec-AH sein.
0 7 15 31
Next Payload
Reserved
Payload Length
Domain of Interpretation (DOI)
Protocol ID
SPI Size
Notify Message Type
Security Parameter Index (SPI) Notification Data

Abbildung 8.12: Die Notification Payload
SPI Size Dieser Wert gibt an, wie gro das Feld Security Parameter Index im bernchsten Bereich der Datenstruktur ist. Falls es sich um eine ISAKMP-Notification handelt, ist dieser Wert irrelevant, da der SPI in diesem Fall aus der Kombination von Initiator- und Responder-Cookie besteht. Notify Message Type Der Typ der Nachricht, der in einem 16 Bit langen Wert kodiert ist, legt fest, um welche Art von Notification Payload es sich handelt. Im Augenblick sind im Standard nur solche Typen festgelegt, die Auskunft ber die Fehlerzustnde geben, aufgrund derenr der Aufbau einer Sicherheitsassoziation gescheitert ist.
238
ISAKMP-Nutzdaten
Security Parameter Index In diesem Feld steht der SPI der empfangenden Gegenstelle. Notification Data Hier stehen nhere Angaben zu dem Fehler, der durch den Notify Message Type spezifiziert wurde.
8.3.10
Delete Payload
Wenn eine Gegenstelle eine Sicherheitsassoziation gelscht hat, schickt sie ihrem Partner diese Nachricht, um dies anzuzeigen. Sie erwartet keine Besttigung mehr, dass der Empfnger die Nachricht erhalten hat . Es wird empfohlen, dass eine Gegenstelle, die eine Delete Payload erhlt, die entsprechende Sicherheitsassoziation ebenfalls lscht, da sie nicht mehr in Benutzung ist und auch nicht reaktiviert werden kann. Domain of Interpretation (DOI) Dieses Feld teilt mit, in welcher Domain of Interpretation (ISAKMP oder IPSec) die Mitteilung erfolgt.
0 7 15 31
Next Payload
Reserved
Payload Length
Domain of Interpretation (DOI)
Protocol ID
SPI Size
Number of SPIs
Security Parameter Index(es) (SPI)
Abbildung 8.13: Die Delete Payload
Protocol ID Hier steht die Protokollnummer des Protokolls, das durch die gelschte SA geschtzt wurde. Im Fall von IP Security knnen dies ISKMP, IPSec-ESP und IPSec-AH sein. SPI Size Dieser Wert gibt die Lnge der SPIs an. Da nur ein einziges Protokoll pro Datenstruktur mglich ist, sind alle SPIs vom gleichen Typ und gleich lang. Falls eine ISAKMP-Sicherheitsassoziation gelscht wird, ist dieser Wert obsolet, da deren SPI aus den beiden Cookies besteht.
239
Number of SPIs Falls mehrere zu einem Protokoll gehrende SPIs gelscht werden, kann dies in einer einzigen Mitteilung erfolgen. In diesem Fall werden die SPIs der gelschten Sicherheitsassoziation nacheinander in einer Delete Payload bertragen. Was jedoch nicht funktioniert, ist, mehrere verschiedene Protokolle in einer Nachricht unterzubringen. Es muss fr jedes Protokoll eine eigene Datenstruktur verwendet werden. Security Parameter Index(es) Hier stehen der oder die gelschten SPIs, falls es sich nicht um eine ISAKMPSA handelt.
8.3.11
Vendor ID Payload
In das Datenfeld dieser Nachricht kann der Hersteller des IPSec-Systems eine selbst definierte Konstante eintragen. Damit kann er seine eigenen Implementierungen und auch verschiedene Versionen davon identifizieren. Die Vendor ID wird nicht selten benutzt, um in der IKE-Phase 2, nach dem Aufbau der ISAKMP-SA, herstellerspezifische Nachrichten und Informationen austauschen zu knnen. Dazu mssen sich beide Gegenstellen die notwendigen IDs zugeschickt haben. Die Vendor ID muss whrend des Aufbaus der ISAKMP-Sicherheitsassoziation ausgetauscht werden; spter, in Phase 2, ist dies nicht mehr mglich.
0 7 15 31
Next Payload
Reserved
Payload Length
Vendor ID (VID)
Abbildung 8.14: Die Vendor ID Payload
Eine mgliche Anwendung der Vendor ID, in Verbindung mit nachfolgenden privaten Payloads, ist die Konfiguration von entfernten IPSec-Clientsystemen mit Parametern wie dynamisch zugewiesenen IP-Adressen, WINS-Adressen, Policies usw. Im Datenfeld selbst wird kein Text eingetragen, sondern ein Hashwert, der im Allgemeinen ber den Namen der Firma, den Produktnamen und eine Versionsnummer berechnet wurde.
240
ISAKMP-Nutzdaten
8.3.12
Die ISAKMP-Phasen
Die Austauschvorgnge im Internet Security Asscociation and Key Management Protocol werden in zwei Phasen unterteilt. In der Phase 1 wird eine ISAKMP-Sicherheitsassoziation aufgebaut, unter deren Schutz dies ist dann die Phase 2 die Austauschvorgnge fr die Sicherheitsprotokolle wie IPSecESP oder IPSec-AH erfolgen knnen. Dies ist natrlich ein etwas zeitaufwendiger Prozess, wenn zum Beispiel fr eine IPSec-ESP-Sicherheitsassoziation vorher noch eine ISAKMP-SA aufgebaut werden muss. Falls aber innerhalb einer Verbindung noch weitere Protokoll-SAs erzeugt werden sollen, kann dies unter dem Schutz der ISAKMP-SA erfolgen, was dann insgesamt nicht mehr so aufwendig ist. Die Austauschvorgnge in den entsprechenden Phasen werden whrend der Beschreibung des IKE-Protokolls ausfhrlich erlutert, deshalb folgt hier nur ein kurzer berblick ber die Phasen als solche: Phase 1 Die Phase 1 ist die Phase, in der noch keine Sicherheitsdienste (Verschlsselung, Integrittsprfung, Authentifizierung) zwischen Initiator und Responder zur Verfgung stehen. Also mssen hier besondere Sicherheitsvorkehrungen greifen. In der Phase 1 wird eine ISAKMP-Sicherheitsassoziation etabliert, die die notwendigen Sicherheitsdienste aushandelt und zur Anwendung bringt, um sowohl sich selbst als auch die Operationen in der folgenden Phase 2 zu schtzen. Phase 2 Die Operationen in der Phase 2 sind bereits durch die Sicherheitsdienste geschtzt, die in der Phase 1 ausgehandelt wurden. Aus diesem Grund kommt man in der Phase 2 auch mit weniger Nachrichten als in der Phase 1 aus, weshalb diese Phase im IKE-Protokoll, das die ISAKMP-Austauschvorgnge benutzt, auch als IKE Quick Mode bezeichnet wird. Hier werden die eigentlichen Security-Protokolle ausgehandelt, die zum Schutz der Nutzdaten dienen, die zwischen den beiden Gegenstellen bertragen werden sollen.
8.3.13
Die ISAKMP-Austauschvorgnge
Im ISAKMP sind verschiedene Austauschvorgnge festgelegt, die auch vom IKE-Protokoll benutzt werden. Diese Vorgnge legen genau fest, in welcher Reihenfolge welche Art von Nachrichten ausgetauscht werden, wie diese Nachrichten aufgebaut sind und wie die Nachrichten von den IKE-Instanzen zu verarbeiten sind. Eine ausfhrliche Beschreibung der Austauschvorgnge und Nachrichten erfolgt in den Kapiteln zum IKE-Protokoll. Hier wird nur ein berblick vermittelt, welche Arten es gibt.
241
Folgende Austauschvorgnge sind im Internet Security Asscociation and Key Management Protocol spezifiziert: Base Exchange Dieser Vorgang besteht aus insgesamt vier Nachrichten, zwei in jede Richtung. In den ersten beiden Nachrichten wird die Sicherheitsassoziation ausgehandelt, die beiden folgenden dienen zum Schlsseltausch und zur Authentifizierung. Die Informationen zur Authentifizierung, also auch zur Identitt der Gegenstellen, und zum Schlsseltausch werden in einer Nachricht zusammengefasst und somit im Klartext bertragen, da zu diesem Zeitpunkt offensichtlich aufgrund der noch fehlenden Schlssel keine Verschlsselung mglich ist. Identity Protection Exchange Hier wird das Manko, dass in der Base Exchange die Informationen zur Identitt der Kommunikationspartner im Klartext bertragen werden, behoben. Allerdings wird dies durch einen Overhead in Form zweier zustzlicher Nachrichten erkauft, so dass hier insgesamt sechs statt vier Nachrichten ausgetauscht werden mssen. Hier werden in den letzten beiden Nachrichten die Informationen zur Identitt bertragen, verschlsselt mit dem Schlssel, der aus den Daten der beiden vorhergehenden Exchanges vom Schlsseltauschprotokoll berechnet wurde. Daher rhrt auch der Name fr diesen Austauschvorgang. Dieser Austausch ist die Grundlage fr den IKE Main Mode, den man in IPSec-Security-Gateways einzusetzen pflegt. Aggressive Exchange Dieser Austausch besteht aus insgesamt nur drei Nachrichten und zeichnet sich dadurch aus, dass in diese Nachrichten so viel an Informationen gepackt wird, wie zum Zeitpunkt des Sendens mglich ist. Ein Schutz der Identitt findet nicht statt, und es besteht eine etwas grere Gefahr von Denial-of-Service-Angriffen, da die notwendigen Umlaufzeiten fr Schutzmanahmen wie Anti-Clogging-Tokens nicht gegeben sind. Dieser Exchange ist die Basis fr den IKE Aggressive Mode, der vor allem in Remote-Access-Applikationen in IPSec-PC-Implementierungen eingesetzt wird. Authentication Only Exchange Dieser Austausch dient ausschlielich dazu, Nachrichten auszutauschen, in denen Informationen zur Authentifizierung enthalten sind. Im IKE-Protokoll finden sie keine Verwendung.
242
Informational Exchange Ein derartiger Austausch besteht nur aus einer einzigen Nachricht. Eine Besttigung ist, trotz Verwendung von UDP als Transportprotokoll, nicht vorgesehen. Dieser Austausch dient zum Management von Sicherheitsassoziationen und zur Information ber Fehlerzustnde.
8.4
Das Oakley Key Determination Protocol ist ein Schlsseltauschprotokoll, das auf der Grundlage von ISAKMP und des Diffie-Hellman-Verfahrens einen authentifizierten Schlsseltausch ermglicht. Es dient neben dem Internet Security Asscociation and Key Management Protocol als Grundlage des IKEProtokolls. Oakley benutzt die Austauschvorgnge des ISAKMP-Protokolls. Das Format der Nachrichten und ihre Verarbeitung wird in den folgenden Kapiteln zu IKE nher erlutert. An dieser Stelle seien jedoch die so genannten Oakley-Gruppen erwhnt. Diese Gruppen spezifizieren die Umgebung, in der ein Schlsseltausch stattfindet, indem sie Grundparameter des Diffie-Hellman-Algorithmus festlegen. Es werden der Generator und die Primzahl angegeben, die als Modulus benutzt wird. Weiterhin wird festgelegt, ob die Gruppe auf elliptischen Kurven oder dem Modulus einer Exponentiation beruht. Das Gruppenkonzept bringt unter anderem den Vorteil, dass sich Schlsseltauschprogramme nur noch auf die Gruppe einigen mssen. Eine bertragung der ganzen anderen notwendigen Informationen kann entfallen, da sie den Gegenstellen ja im Voraus bekannt sind. Im IKE-Protokoll muss die Oakley-Gruppe 1 untersttzt werden, andere Gruppen sind optional. In die Gruppen wurde sehr viel an Arbeit investiert, so wurden zum Beispiel alle Primzahlen getestet, was bei einer 1536 Bit groen Primzahl doch schon einiges an Aufwand erfordert. Es sind zur Zeit fnf wohl bekannte Oakley-Gruppen definiert.
8.4.1
Die Oakley-Gruppe-1
Diese Gruppe basiert auf modularer Exponentiation und verwendet eine 768 Bit groe Primzahl als Modulus und den Generator 2. Um sich ein Bild von dieser 232-stelligen Primzahl machen zu knnen, sei sie hier einmal in dezimaler Schreibweise dargestellt: 1.552.518.092.300.708.935.130.918.131.258.481.755.631.334.049.434.514.313.202. 351.194.902.966.239.949.102.107.258.669.453.876.591.642.442.910.007.680.288.8 64.229.150.803.718.918.046.342.632.727.613.031.282.983.744.380.820.890.196.28 8.509.170.691.316.593.175.367.469.551.763.119.843.371.637.221.007.210.577.919
243
Der Diffie-Hellman-Algorithmus bildet seinen ffentlichen Wert, indem er die Zahl 2, den so genannten Generator, mit einer 180 Dezimalstellen groen Zufallszahl, dem privaten Wert, exponenziert und durch die obige Primzahl modulo dividiert. Das Ergebnis ist der ffentliche Wert des Diffie-HellmanVerfahrens, der ber ein unsicheres Medium zur Gegenseite geschickt werden kann. Man kann hier auch erkennen, dass solche Verfahren einiges an Rechenzeit verschlingen, und sollte sich dies beim Design seines VPN vor Augen halten. Diese Gruppe muss in IKE implementiert werden, alle anderen Gruppen sind optional.
8.4.2
Die Oakley-Gruppen 2 bis 5
Die restlichen Oakley-Gruppen definieren eine modulare Exponentiation mit einem 1024-Bit-Modulus (Gruppe 2) und einem 1536 Bit groen Modulus (Gruppe 5) oder basieren auf Gruppen elliptischer Kurven ber Galois-Feldern mit 2155 Feldelementen (Gruppe 3) oder 2185 Elementen (Gruppe 4). Diese Gruppen sind optional, die meisten Implementierungen untersttzen zustzlich zur obligatorischen Gruppe 1 noch die Gruppe 2 mit einer 1024 Bit groen Primzahl.
8.5
Der Aufbau von IKE
Das Internet-Key-Exchange-Protokoll benutzt ISAKMP, Oakley und die IPSec Domain of Interpretation, um Sicherheitsassoziationen fr Sicherheitsprotokolle zu erzeugen und den erforderlichen Schlsseltausch durchzufhren. Das Konzept des universellen Schlsseltauschprotokolls SKEME (Secure Key Exchange Mechanism) diente als Grundlage fr IKE. Obwohl alle diese Protokolle einen mehr oder minder starken Einfluss auf das Internet-Key-Exchange-Protokoll hatten, ist es ein von diesen vllig unabhngiges, eigenstndiges Protokoll. Zustzlich zu den in ISAKMP festgelegten Austauscharten werden in IKE zwei neue Exchanges eingefhrt: der Quick Mode und der New Group Mode. Der Quick Mode wird in Phase 2 eingesetzt und dient dazu, auf schnelle Art und Weise mit nur drei Nachrichten eine IPSec-Sicherheitsassoziation aufzubauen. Der New Group Mode wird dazu benutzt, zwischen Initiator und Responder eine neue Oakley-Gruppe mit allen notwendigen Parametern zu vereinbaren. Er wird genau genommen zwischen Phase 1 und Phase 2 ausgehandelt, denn sein Ergebnis muss der Phase 2 bereits zur Verfgung stehen. Andererseits darf der New Group Mode nur unter dem Schutz einer ISAKMPSicherheitsassoziation ausgehandelt werden, was in Phase 1 geschieht.
244
Der Aufbau von IKE
IKE definiert alle notwendigen Austauschvorgnge so weit, dass es unmittelbar zu implementieren ist und zwar sowohl mit der IPSec DOI fr IP-Security-Protokolle als auch unter Verwendung anderer DOIs auch mit anderen Protokollen. Hier interessiert aber nur der Einsatz in Verbindung mit IPSec. Das IKE-Protokoll legt auch ein Rollenverhalten fr die beteiligten Gegenstellen fest und unterscheidet zwischen dem Initiator, der, wie der Name bereits vermuten lsst, die Kommunikationsvorgnge beginnt, und dem Responder, der darauf antwortet. IKE benutzt Nachrichten und Austauschvorgnge von ISAKMP und benutzt dessen Daten- und Paketformate. Ebenso wird dessen Modell der beiden Phasen umgesetzt, innerhalb derer die notwendigen Sicherheitsassoziationen erzeugt werden. In Phase 1 sind drei Austauschvorgnge (Exchange) mglich: der IKE Main Mode, der auf dem ISAKMP Identity Protection Exchange aufbaut, der IKE Aggressive Mode, abgeleitet vom gleichnamigen ISAKMP-Austauschvorgang, sowie der Informational Exchange. In der Phase 2 gibt es den so genannten IKE Quick Mode, der keine ISAKMP-Entsprechung hat, jedoch auf dessen Nachrichten und Informationsformaten basiert. Das Oakley Key Determination Protocol liefert die notwendigen Grundlagen fr einen sicheren und authentifizierten Schlsseltausch. Dort sind auch die Oakley-Gruppen mit allen notwendigen Funktionen definiert, um die notwendige Umgebung spezifizieren, in der die Austausch- und Berechnungsvorgnge stattfinden.
8.5.1
Perfect Forwarding Secrecy
Auf praktisch allen heute verfgbaren IPSec-Security-Gateways und IPSecHostimplementierungen kann man optional die so genannte Perfect Forwarding Secrecy (PFS) aktivieren. Diese Option legt fest, wie Schlssel in einer Sicherheitsassoziation generiert werden. Hierzu gibt es grundstzlich zwei verschiedene Mglichkeiten: Entweder man generiert alle Schlssel auf Basis der gleichen Grunddaten, oder man erzeugt Schlssel immer aus vllig neuen, von den bisher benutzten vllig unabhngigen Daten. Letzteres bezeichnet man als Perfect Forwarding Secrecy. Dadurch wird erreicht, dass die nachfolgenden Schlssel nicht von einer Kompromittierung eines Schlssels betroffen sind, egal wodurch diese zustande kam. Denn ohne PFS wre es denkbar sofern ein Schlssel bekannt wre , dass Schlssel, die aus dem gleichen Hauptschlssel erzeugt werden, ebenfalls bekannt werden knnten. Mit PFS hingegen ist garantiert, dass alle Schlssel, die unter dieser Option erzeugt wurden, vllig unabhngig voneinander sind.
8.5.2
Die Attribute einer IPSec-Sicherheitsassoziation
Die Attribute einer IPSec-Sicherheitsassoziation werden in der IKE-Phase 2 zwischen dem Initiator und Responder ausgehandelt. Sie dienen dazu, zustzlich zu den ausgehandelten Sicherheitsdiensten der Protection Suite
245
weitere Optionen zwischen den Gegenstellen zu vereinbaren. Diese Attribute werden in speziellen ISAKMP-Nutzlastformaten bertragen. Hierbei unterscheidet man grundstzlich zwischen Attributen variabler und fester Lnge, was auch das Format der Pakete bestimmt. Das erste Bit in der Datenstruktur, die zur bertragung eingesetzt wird, legt fest, ob es sich um ein Attribut fester (1) oder variabler (0) Lnge handelt. Das zweite 15 Bit lange Feld legt den Typ des Attributs fest, und das dritte Feld enthlt entweder den Wert oder die Lnge des Attributs, je nachdem, ob es eine feste Lnge hat oder nicht. Falls es ein Attribut variabler Lnge ist, ist noch ein viertes Feld vorhanden, in dem der Attributwert enthalten ist. Es gibt eine Reihe verschiedener Attribute, von denen folgende obligatorisch fr die Aushandlungen in der Phase 2 (IPSec-Aushandlung) einer IKE-Implementierung sind: SA Life Type SA Life Duration Authentication Algorithm Optionale IPSec-Attribute SA Life Type Dieses Attribut legt die Einheit in Sekunden oder Kilobyte fest, in der die Lebensdauer der vorliegenden Sicherheitsassoziation angegeben ist. In der Regel sollte man eine Lebensdauer auf Basis bertragener Pakete festlegen, denn nur damit kann man seine Sicherheitsstrategie darauf ausrichten, wie viele Daten maximal entschlsselt werden knnen, falls der dazugehrige Schlssel kompromittiert ist. SA Life Duration Hiermit wird die Lnge der Lebensdauer der vorliegenden SA abhngig vom SA Life Type in Sekunden oder Kilobyte festgelegt. Hier ein Tipp, falls es bei IPSec-Implementierungen verschiedener Gerte zu Problemen beim Aufbau einer SA kommt. Oft sind unterschiedliche Werte in den beteiligten Endgerten die Ursache fr derartige Probleme. Der Standard, hier die IPSec DOI, schreibt kein verbindliches Verhalten vor, falls aufgrund der Sicherheitsstrategie des Responders die vom Initiator vorgeschlagene Lebenszeit nicht akzeptabel ist. Hier gibt es drei Mglichkeiten: Entweder kann die Aushandlung sofort scheitern, der Responder akzeptiert das Proposal, benutzt aber einfach seine eigenen Werte ohne Rckmeldung an den Initiator, oder er akzeptiert den Vorschlag, benutzt seine eigene Lebensdauer und informiert den Responder mit einem informellen Nachrichtenpaket ber seinen eigenen Wert.
246
Der Aufbau von IKE
Authentication Algorithm Dieser Wert muss vorhanden sein, um den korrekten Authentifizierungsalgorithmus fr IPSec-ESP oder IPSec-AH festzulegen. Es gibt nur eine Ausnahme, in der dieser Wert nicht prsent muss, und zwar dann, wenn IPSecESP ohne Authentifizierung benutzt wird. In diesem Fall darf dieser Wert nicht vorhanden sein. Optionale IPSec-Attribute Weitere optionale IPSec-Attribute spezifizieren Dinge wie IPSec-Modi (Tunnel- oder Transportmodus), weitere Oakley-Gruppen, Werte fr spezielle Verschlsselungsalgorithmen mit variabler Schlssellnge und Rundenzahl und private Komprimierungsverfahren. Folgende Attribute sind in der IPSec Domain of Interpretation festgelegt: Group Description Encapsulating Mode Key Length Key Rounds Compress Dictionary Size Compress Private Algorithm
8.5.3
Die Attribute einer ISAKMP-Sicherheitsassoziation
Im Internet Key Exchange Protocol gibt es noch eine Reihe weiterer Attribute, die in der Phase 1 zur Aushandlung der ISAKMP-SA benutzt werden und daher nicht im IPSec-DOI, sondern direkt im IKE-Protokoll festgelegt sind: Encryption Algorithm Hash Algorithm Authentication Method Group Attributes Life Type Life Duration PRF Key Length Field Size Group Order
247
Encryption Algorithm Dieses Attribut legt den Verschlsselungsalgorithmus fest, der zur Verschlsselung der IKE-Nachrichten benutzt wird. Folgende Algorithmen sind im Augenblick von der IANA (Internet Assigned Numbers Authority) festgelegt, weitere knnen folgen oder privat zwischen zwei Gegenstellen festgelegt werden: DES-CBC (obligatorisch) Triple-DES-CBC IDEA-CBC Blowfish-CBC RC5-R16-B64-CBC CAST-CBC Im Augenblick gibt es noch keinen festgelegten Wert fr den Advanced Encryption Standard, jedoch sind bereits Arbeiten innerhalb der IETF im Gange, diesen nach seiner offiziellen Standardisierung in IPSec und IKE zu implementieren. Hash Algorithm Das Hashverfahren, das innerhalb von IKE zur Integrittsprfung und Authentifizierung benutzt werden kann, kann aus den drei folgenden Algorithmen ausgewhlt werden: MD5 (obligatorisch) SHA (obligatorisch) Tiger Die Algorithmen mssen sowohl den HMAC als auch ihren natrlichen Modus untersttzen. Falls kein PRF-Attribut (siehe unten) zwischen den beiden Gegenstellen vereinbart wird, dann werden diese Algorithmen als Pseudo Random Function (PRF) in IKE benutzt, unter anderem auch, um den Hauptschlssel zu berechnen. Authentication Method Hier wird festgelegt, welche Authentifizierungsmethode in der Phase 1 benutzt wird. Folgende Varianten sind aushandelbar: Pre-Shared Key (obligatorisch) DSS Signatures RSA Signatures
248
Der Aufbau von IKE
Encrypt with RSA Revised Encryption with RSA Die Aushandlung einer Authentifizierungsmethode hat einen entscheidenden Einfluss auf das Verhalten der Aushandlungen und ihre Nachrichtenformate. Group Attributes Diese Attribute ermglichen es, eine andere als die Oakley-Gruppe 1 zwischen Initiator und Responder zu vereinbaren, die spter weiteren Austauschvorgngen in der Phase 2 zur Verfgung stehen kann. Dabei kann auf wohl bekannte Oakley-Gruppen zurckgegriffen werden, indem man einfach deren Gruppenattribut austauscht oder man komplett neue Gruppen spezifiziert und die notwendigen Parameter wie Primzahlen, Generatoren, Kurvenparameter usw. austauscht. Die auf modularer Exponentiation basierende Gruppe 1, mit einer 768 Bit groen Primzahl, ist in IKE obligatorisch. Folgende Parameter knnen zustzlich zur Gruppennummer (Group Description) ausgetauscht werden, um eine andere Gruppe zu erzeugen: Group Description Default 768-Bit-MODP Group (obligatorisch) Alternate 1024-Bit-MODP Group EC2N Group on GP[2155] EC2N Group on GP[2185] Group Type MOP (Modulare Exponentiation) ECP (Elliptische Kurven ber Galois-Feld GF[P]) EC2N (Elliptische Kurven ber Galois-Feld GF[2N]) Group Prime or Irreducible Polynomial Group Generator One Group Generator Two Group Curve A Group Curve B Life Type Damit wird die Einheit der Lebensdauer der ISAKMP-SA festgelegt. Diese kann in Sekunden oder Kilobyte angegeben werden.
249
Life Duration Hierin wird die Lnge der Lebensdauer der vorliegenden SA in der im Attribut Life Type ausgehandelten Einheit angegeben. PRF Dieses Attribut wird in fast keiner Implementierung benutzt. Es gibt auch keine Spezifikationen hierzu. Als PRF (Pseudo Random Function) werden in IKE daher meist die HMAC-Versionen des ausgehandelten Hashalgorithmus verwendet. Jedoch knnen Implementierungen auch private Funktionen angeben und in einer IKE-Aushandlung vereinbaren. Key Length Bei Verschlsselungsalgorithmen mit variabler Schlssellnge muss hier die verwendete Gre des Schlssels angegeben werden. Falls Algorithmen mit fester Schlssellnge benutzt werden, darf dieses Attribut nicht verwendet werden. Field Size Die Feldgre in Bits einer Diffie-Hellman-Gruppe wird in diesem Attribut bertragen. Group Order Hierin werden Angaben zur Gruppenreihenfolge zu einer Diffie-HellmannGruppe bertragen, die mit elliptischen Kurven arbeitet.
8.5.4
IKE-Sicherheitsverfahren
Im Internet-Key-Exchange-Protokoll werden sowohl bidirektionale ISAKMPSicherheitsassoziationen als auch unidirektionale SAs fr die Sicherheitsprotokolle von IPSec erzeugt. Zu jeder SA existiert eine so genannte Protection Suite (PS), die von den beiden Seiten ausgehandelt wurde und festlegt, welche Sicherheitsverfahren benutzt werden, um die Daten zu schtzen, die innerhalb der SA bertragen werden. Standard-konforme Implementierungen von IKE und den IP-Security-Protokollen knnen immer sofern beide Gegenstellen eine zueinander passende Sicherheitsstrategie verfolgen eine Sicherheitsassoziation erzeugen. Das wird garantiert, indem alle Implementierungen einen Mindestsatz von Sicherheitsdiensten zur Verfgung stellen mssen, auf die sich alle Beteiligten einigen knnen. Alle IKE-Implementierungen mssen folgende Dienste fr ihre ISAKMP-Sicherheitsassoziation zur Verfgung stellen und aushandeln knnen: DES als Verschlsselungsalgorithmus MD5 und SHA als Hashverfahren
250
Der Aufbau von IKE
Authentifizierung mittels Pre-Shared Key Modulare Exponentiation in der Oakley-Gruppe 1 Weitere Dienste wie Triple-DES oder andere Hashalgorithmen sind optional und sollten, mssen aber nicht zur Verfgung stehen. In der Praxis werden auch meist Triple-DES und gelegentlich die Oakley-Gruppe 2 implementiert, um etwas mehr an Sicherheit zu bieten.
8.5.5
Die Schlsselerzeugung in IKE
Die Erzeugung der Schlssel in IKE ist ein Punkt, dem man eine gewisse Beachtung schenken sollte, nicht zuletzt deshalb, weil damit auch ein Teil der oft hitzig gefhrten Diskussionen um Schlssellngen etwas an Bedeutung verliert. Wenn Sie bereits in dem Stadium sind, fr Ihr geplantes IPSec-VPN bestimmte Gateways und Client-Implementierungen auszuwhlen, werden Sie sich nicht selten fragen, wie denn Systeme verschiedener Hersteller mit 112-Bit-TripleDES, 168-Bit-Triple-DES und 192-Bit-Triple-DES oder einfach nur Triple-DES miteinander kommunizieren knnen. Obendrein treten dann noch Anbieter mit so genannter 128-Bit-Software auf den Plan und behaupten, wie alle anderen auch, mit den brigen kompatibel zu sein. Nach dem was in Kapitel 4 beschrieben wurde, kann das eigentlich gar nicht mglich sein. Ist es auch nicht. Leider sind viele dieser Angaben, milde ausgedrckt, unprzise, aus dem Zusammenhang gebracht und in einigen Fllen schlicht falsch. Um die Zusammenhnge etwas zu verdeutlichen, betrachten wir an dieser Stelle, ohne hier den genauen Ablauf der Nachrichten zum Schlsseltausch kennen zu mssen, wie die IKE-Schlssel fr die IKE- und IPSec-ESP-Sicherheitsassoziationen erzeugt werden. Nehmen wir einmal der Einfachheit halber an, beide SAs sollen Triple-DES als Verschlsselungs- und MD5 als HashAlgorithmus benutzen. Man bentigt also drei Schlssel mit je 56 Bit Lnge (aus einem 64-Bit-String). Nehmen wir weiterhin an, es erfolge eine Authentifizierung mit einem Pre-Shared Key im IKE Main Mode. Dann wrde die Erzeugung der Schlssel zur Verschlsselung der Nutzdaten auf folgende Art und Weise erfolgen: Es werden verschiedene Schlssel berechnet: ein Grundschlssel (SKEYID), aus dem alle weiteren Schlssel abgeleitet werden, ein Schlssel (SKEYID_e) zur Verschlsselung der ISAKMP-SA, ein Schlssel (SKEYID_a) zur Authentifizierung der Nachrichten und ein Schlssel (SKEYID_d), aus dem in nachfolgenden IPSec-Sicherheitsassoziationen in Phase 2 weitere Schlssel generiert werden knnen. Diese Schlssel werden im Fall der Authentifizierung mit einem Pre-Shared Key auf folgende Weise erzeugt:
251
SKEYID = HMAC-MD5(Pre-Shared Key + Ni) SKEYID_d = HMAC-MD5(SKEYID + KE + Ci + Cr + 0x00) SKEYID_a = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x01) SKEYID_e = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x02) Das Pluszeichen steht fr eine Verkettung der Werte. Die Bezeichner Ci und Cr sind die Werte der Initiator- und Responder-Cookies. An diesem Beispiel, an dem uns hier nicht so sehr die Art der Berechnung interessiert, sieht man sehr gut, dass alle vier Schlssel nur so lang sein knnen wie die Ausgabe der Hashfunktion, in unserem Fall 128 Bit. Falls aus diesem Wert nun die erforderlichen Werte fr den Triple-DES-Algorithmus in der ISAKMP-SA gewonnen werden sollen, muss dieser Wert auf mindestens 192 Bit vergrert werden. Dies erfolgt durch eine relativ einfache und schnelle Verkettungsfunktion: KEYMAT = K1 + K2 mit: K1 = HMAC-MD5(SKEYID_e + 0x00) K2 = HMAC-MD5(SKEYID_e + K1) Aus diesem 256 Bit langen String knnen die drei Teilschlssel fr Triple-DES extrahiert werden. Allerdings und an dieser Stelle sollte man auf diesen Punkt hinweisen ist diese Methode nicht geeignet, tatschlich eine kryptographische Strke des Schlssels von tatschlich 168 Bit zu gewhrleisten. Bei den verwendeten Schlssellngen ist dies zwar kein Sicherheitsproblem, aber eine Brute-Force-Attacke msste in diesem Fall nicht alle 2168 Mglichkeiten von Triple-DES ausprobieren, sondern nur die 2128 Mglichkeiten von SKEYID_e und knnte daraus mit obiger, schnell auszufhrender Rechenanweisung die drei Teilschlssel generieren. Aber wenn man die Kosten hierfr, also die Berechnungszeit fr KEYMAT, mit einkalkuliert, dann liegt die Sicherheit hier immer noch deutlich ber 128 Bit, was in jedem Fall heutzutage ausreichend ist. Aus dem Schlssel SKEYID_d werden alle Schlssel fr unsere IPSec-ESPSicherheitsassoziation erzeugt, also die drei 56-Bit-Schlssel fr Triple-DES und der 128-Bit-Schlssel fr HMAC-MD5-96. Falls als Option Perfect Forwarding Secrecy (PFS) ausgehandelt wurde, erfolgt in der IKE-Phase 2, im QuickMode-Austausch, nochmals ein neuer Diffie-Hellman-Schlsseltausch; es stehen also wieder neue KE-Werte zur Verfgung. Wenn keine PFS eingesetzt wird, benutzt man in dieser Phase einfach die Werte aus der Phase 1. Nachdem diese Austauschvorgnge abgeschlossen sind, wird im IKE Quick Mode das Schlsselmaterial erzeugt, das von den IPSec-ESP-Sicherheitsprotokollen bentigt wird. Das Schlsselmaterial ist eine Bitfolge ausreichender Lnge, aus der die Schlssel fr Triple-DES und HMAC-MD5 extrahiert wer-
252
Der Aufbau von IKE
den. Dies hat selbstverstndlich auf allen Seiten in der gleichen Art zu erfolgen, denn sonst wre offensichtlich keine Entschlsselung oder Authentifizierung auf der jeweils anderen Gegenstelle mehr mglich, da es sich um symmetrische Algorithmen handelt, die identische Werte bentigen! Aus diesem Grund wurde in dem Standard zur Sicherheitsarchitektur fr IPSec (RFC2401) und einem weiteren Dokument zu Benutzung von Verschlsselungsalgorithmen in IPSec (RFC2451) genau festgelegt, wie aus einem hinreichend langen Schlsselmaterial die bentigten Schlssel extrahiert werden mssen. Der RFC2401 legt dabei Folgendes fest: Fr symmetrische Verschlsselungsverfahren werden die Schlssel aus den n hchstwertigen Bits extrahiert, und die restlichen Bits werden fr die Hashalgorithmen im HMACModus benutzt, wobei die Zahl n die Summe aller bentigten Bits des Verschlsselungsverfahrens ist. Der RFC2451 legt fest, wie die verschiedenen Algorithmen mit Schlsseln versorgt werden. In unserem Fall wird dort spezifiziert, dass Triple-DES mit drei unabhngigen Teilschlsseln von je 64 Bit Lnge, also insgesamt 192 Bits, versorgt werden muss. In jedem Schlssel wird spter jedes achte Bit entfernt, so dass drei Schlssel mit 56 Bit zur Verfgung stehen. Also bentigen wir fr unsere Sicherheitsassoziation Schlsselmaterial mit insgesamt mindestens 320 Bit Lnge. Dies wird in IKE auf folgende Weise erzeugt: KEYMAT = K1 + K2 + K3 wobei K1 bis K3 auf folgende Weise erzeugt werden: K1 = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + KE + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + KE + Protokoll + SPI + Ni + Nr) Hier wird ein 384 Bit langer Wert erzeugt, dessen erste 320 Bit zur Verwendung als Schlssel in der IPSec-ESP-Sicherheitsassoziation herangezogen werden. Bei dieser Verkettungsfunktion ist, im Gegensatz zu der fr die ISAKMP-SA benutzten, die Mglichkeit gegeben (wie in unserem Beispiel zu sehen), durch Benutzung der Perfect Forwarding Secrecy die Daten der neuen Schlsselaushandlung (KE) in Phase 2 mit in die Berechnung aufzunehmen. Auf diese Weise wird eine hohe kryptographische Strke des Schlsselmaterials erreicht. Damit wurde aufgezeigt, dass Triple-DES in IPSec-ESP mit drei unabhngigen Teilschlsseln zu je 56 Bit arbeitet (aus den 64 Bits der drei ursprnglichen Teilschlssel wurde jedes achte Bit entfernt), was eine Gesamtlnge von 168 Bit ergibt. Es gibt im standardkonformen IPSec keine Schlssellngen von 128 oder 192 Bit und schon gar keine Implementierung, die mit Triple-DES und zwei unabhngigen Teilschlsseln mit insgesamt 112 Bit arbeitet! Solche Implementierungen, wenn es sie denn gbe, wren zu allen anderen Systemen inkompatibel.
253
An dieser Stelle sei noch erwhnt, dass die Sicherheit dieser ganzen Verfahren davon abhngt, dass beide Seiten einer Sicherheitsassoziation den Schlsseltausch (und insbesondere die privaten Zufallszahlen des Diffie-Hellman-Verfahren) vernnftig und sicher erzeugen und diese Werte sobald mglich vernichten. Sobald nur eine Seite ein bses Spiel treibt und in der Zufallszahl nur eine Entropie von zum Beispiel 20 Bit htte oder die Zahl gar speichert und weitergibt, wre damit die ganze Sicherheit der Verbindung verloren, egal wie gut die Gegenstelle ihre eigene Zufallszahl erzeugt! Denn das Wesen des Diffie-Hellman-Austauschs liegt gerade darin, dass zur Erzeugung des Schlssels nur der eigene private Wert bentigt wird.
8.5.6
IKE-Authentifizierung
IKE legt in der Aushandlung der Sicherheitsassoziation weiterhin fest, auf welche Art die Authentifizierung erfolgen soll. IKE erlaubt die folgenden vier verschiedenen Methoden: Pre-Shared Key Digital Signature Public Key Encryption (RSA) Revised Mode of Public Key Encryption (RSA) Pre-Shared Key Hier erfolgt die Authentifizierung durch Bildung eines Hashwertes ber eine ganze Reihe von Werten durch die vereinbarte Hashfunktion. Die Werte bestehen aus dem Hauptschlssel, der unter anderem aus dem Pre-Shared Key berechnet wurde, den gesamten Nutzdaten der Sicherheitsassoziation (Proposals), den ffentlichen Diffie-Hellman-Werten, den beiden Cookies und den Identitten von Initiator und Responder. Die Hashfunktion (PRF, Pseudo Random Function) wird entweder explizit fr die SA ausgehandelt, oder es wird die HMAC-Variante der allgemein ausgehandelten Hashfunktion benutzt. Digital Signature Die Authentifizierung erfolgt durch die digitale Signatur eines Hashwertes, der analog zu dem obigen erzeugt wurde. Die Signatur erfolgt mit dem privaten Schlssel und einem Signaturalgorithmus, meist RSA. Optional knnen noch von der Gegenstelle die Zertifikate des Gegenbers angefordert werden, um dessen ffentlichen Schlssel zu bekommen, falls dieser nicht lokal gespeichert oder ber einen Verzeichnisdienst online zur Verfgung steht. Die Zertifikate werden dann zusammen mit der Signatur bertragen.
254
Der Aufbau von IKE
Public Key Encryption (RSA) In diesem Verfahren werden so genannte Nonces, spezielle Zufallszahlen, sowie die Identitten mit dem ffentlichen Schlssel der Gegenstelle verschlsselt. Zu diesem Zweck muss der Initiator den ffentlichen Schlssel des Responders bereits vorher kennen. Als Verfahren wird meist RSA eingesetzt, und der Chiffretext muss im PKCS#1-Format kodiert sein. Die PKCS-Formate sind Industriestandards der Firma RSA Data Security und auf deren Webseite beschrieben. Leider wird diese Art der Authentifizierung nicht oft benutzt, obwohl sie vom Sicherheitsstandpunkt erhebliche Vorteile, auch gegenber digitalen Signaturen, aufweist. Der Grund liegt in der Performance, die hier bentigt wird, denn zustzlich zum Diffie-Hellman-Schlsseltausch sind vier zustzliche Public-Key-Ver- bzw. Entschlsselungen pro Gegenstelle notwendig. Somit ist diese Art der Authentifizierung in Systemen wie Remote-AccessVPN-Konzentratoren, die teilweise eine groe Anzahl von Verbindungen in kurzer Zeit aufnehmen mssen, nicht praktikabel, weil die Public-Key-Verfahren praktisch die komplette Rechenzeit okkupieren und den Anmeldevorgang sehr stark verzgern und den laufenden Datenverkehr stren wrden. Hier msste man sehr viel in umfangreiche Ressourcen, wie Hardwarebeschleuniger fr Public-Key-Verfahren, investieren, was ein solches System in der Summe sehr teuer machen wrde. Revised Mode of Public Key Encryption (RSA) Also hat man das Verfahren revidiert und die Zahl der Public-Key-Operationen reduziert. Hier wird zwar der Nonce-Wert immer noch mit dem ffentlichen Schlssel verschlsselt, jedoch wird die Identitt mit dem ausgehandelten symmetrischen, etwa 1000fach schneller arbeitenden Verfahren verschlsselt. Der Schlssel wird aus dem Nonce abgeleitet und auch gleichzeitig benutzt, um die Nachrichten zum Schlsseltausch zu verschlsseln. Von der Art der Authentifizierung im IKE-Protokoll hngt auch die Art und Weise ab, mit der die Hauptschlssel berechnet werden, aus denen sich die Schlssel zur Verschlsselung, Integrittsprfung und Authentifizierung ableiten. Heutige Implementierungen basieren hauptschlich auf den ersten beiden Verfahren mit Pre-Shared Key oder digitalen Signaturen. Die beiden anderen Verfahren, insbesondere das letzte, haben leider bisher nur wenig Verbreitung gefunden. Deshalb leider, weil man in einem IKE Aggressive Mode Exchange mit den Public-Key-Verfahren die Identitten der Kommunikationspartner schtzen knnte, da sie in jedem Fall verschlsselt bertragen werden.
255
8.6
Der IKE Main Mode
Im IKE Main Mode wird eine ISAKMP-Sicherheitsassoziation erzeugt. Hierfr stehen zwei Austauschtypen zur Verfgung: der so genannte IKE Main Mode, eine Instanziierung des ISAKMP Identity Protection Exchange, und der IKE Aggressive Mode. Sie unterscheiden sich durch die Anzahl von benutzten Nachrichten und die damit verbundene Sicherheitsstufe. Unter bestimmten Bedingungen kann eine Sicherheitsstrategie sogar den Einsatz des Aggressive Mode verbieten. Im Folgenden sind die Austauschvorgnge im Main Mode beschrieben. Da sie sich, je nach dem ausgehandelten Verfahren zur Authentifizierung, sehr stark in den Formaten und Bedeutungen der Nachrichten unterscheiden, werden sie fr jede Version der bersichtlichkeit halber einzeln beschrieben. Bei den im Folgenden beschriebenen Main-Mode-Austauschvorgngen wird von folgenden gleichen Bedingungen ausgegangen: Es sollen DES-CBC, MD5 und die Oakley-Gruppe 1 ausgehandelt und benutzt werden. Die vier Beispiele unterscheiden sich nur in der Art der Authentifizierung.
8.6.1
Authentifizierung mit Pre-Shared Key
Die Authentifizierung dieses Austauschs basiert auf einem Pre-Shared Key, also einer Information, die beiden Systemen zur Verfgung steht. Die praktische Implementierung sieht in der Regel so aus, dass der Pre-Shared Key manuell auf den Systemen eingetragen wird oder bei IPSec-Hostimplementierungen aus dem Benutzerpasswort gewonnen wird. Der IKE Main Mode besteht aus sechs Nachrichten, die nach ihrer Reihenfolge und nach ihren Aufgaben nach in drei Gruppen zu unterteilen sind: Aushandlung der Sicherheitsassoziation, Schlsseltausch und Authentifizierung. Wie in Abbildung 8.15 zu sehen ist, beginnt der Austausch mit zwei Nachrichten, in denen sich Initiator und Responder auf eine Protection Suite fr die ISAKMP-Sicherheitsassoziation einigen oder auch nicht, falls die Vorschlge fr den Responder nicht akzeptabel sind. Im Gegensatz zu anderen Protokollen, wie zum Beispiel PPP, findet hier keine mehrstufige Verhandlung statt, sondern der Initiator unterbreitet eine Reihe von Vorschlgen in einer einzigen Nachricht, und der Responder whlt einen Vorschlag davon aus oder lehnt alles ab. In letzterem Fall kommt die Aushandlung zum Ende, indem sie schlicht terminiert wird. Die Vorschlge (Proposals) des Initiators knnen sehr komplex aufgebaut und logisch (Und, Oder) miteinander verknpft werden. Bei bestimmten Umgebungen, zum Beispiel im Fall von Remote-AccessVPNs, in denen eine zentrale Sicherheitsstrategie eingesetzt wird, sieht es in der Praxis meist so aus, dass der Initiator alles in einen Vorschlag packt, was er an Funktionen untersttzt, und das zentrale VPN-Gateway aus diesem Packen das Proposal auswhlt, das seiner Sicherheitsstrategie entspricht.
256
Der IKE Main Mode
Sobald die ersten beiden Nachrichten ausgetauscht, verarbeitet und ausgewertet sind, steht fest, ob sich Initiator und Responder auf eine ISAKMPSicherheitsassoziation einigen konnten oder nicht. Im letzteren Fall wird der Verbindungsaufbau abgebrochen; ansonsten wird durch den vom Responder ausgewhlten Vorschlag der weitere Verlauf des Austauschvorgangs festgelegt. In unserem Fall soll eine Authentifizierung auf Basis eines Pre-Shared Key erfolgen.
Initiator Responder
Nachricht 1
Hdr SA Proposal 1 Transf. 1
...... Proposal n
Transf. n
Nachricht 2
Hdr SA
Proposal Transform
Abbildung 8.15: Die ersten beiden Nachrichten des IKE Main Mode
Die folgenden beiden Nachrichten dienen zur bertragung von Informationen, mit deren Hilfe der Initiator und der Responder lokal den symmetrischen Hauptschlssel berechnen knnen. Zu diesem Zweck erzeugen sich beide je zwei strikt zufllige Zahlen, von denen eine als Exponent (x im Initiator und y im Responder) fr das Diffie-Hellman-Verfahren und die andere als Nonce-Wert dient. Da sich beide Seiten auf die Oakley-Gruppe 1 geeinigt haben, werden nun die ffentlichen Diffie-Hellman-Werte aus der Basis 2, der 768 Bit groen Primzahl n und dem geheimen Exponenten berechnet. Der Initiator erzeugt seinen Wert mit 2x (mod n), und der Responder berechnet 2y (mod n). Die Zahlen 2 und n brauchen nicht ausgetauscht zu werden, da sie implizit durch Auswahl der Oakley-Gruppe 1 in den beiden ersten Nachrichten festgelegt wurden. Aus diesen ganzen Werten formen der Initiator und der Responder die bentigten Datenstrukturen fr ihre Nachrichten und tauschen diese anschlieend aus, wie in Abbildung 8.16 zu sehen ist. Es erfolgt aber auf keiner der beiden Seiten sofort eine Berechnung des Hauptschlssels. Dies wird so lange verzgert, bis die Cookies ausgewertet sind und damit der jeweilige Absender verifiziert ist. SKEYID = HMAC-MD5(Pres-Shared Key + Ni) SKEYID_d = HMAC-MD5(SKEYID + KE + Ci + Cr + 0x00) SKEYID_a = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x01) SKEYID_e = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x02)
257
SKEYID_e wird zur Verschlsselung der ISAKMP-Nutzdaten benutzt, und SKEYID_a dient zur Authentifizierung der Pakete mit Hilfe der ausgehandelten Hashfunktion. In unserem Beispiel sind dies DES zur Datenverschlsselung und HMAC-MD5 als Hash-Algorithmus. Der Schlssel SKEYID_d dient als Grundschlssel der IPSec-SAs, die in der IKE-Phase 2 erzeugt werden.
Initiator Responder
Nachricht 3
Hdr KE i
Ni
Nachricht 4
Hdr KE r
Nr
Abbildung 8.16: Die beiden Nachrichten zum Schlsseltausch im IKE Main Mode
An diesem Beispiel wird offensichtlich, dass falls eine Authentifizierung mit einem Pre-Shared Key durchgefhrt wird der Responder wissen muss, wessen Pre-Shared Key er fr die Berechnung von SKEYID benutzen soll. Er besitzt die Keys aller mglichen Gegenstellen und muss einen davon auswhlen. Die Identitt des Initiators wird ihm aber erst in der vorletzten Nachricht mitgeteilt, die jedoch bereits verschlsselt sein muss, und zwar mit einem Schlssel, der teilweise auf dem Pre-Shared Key basiert. Als einzige Mglichkeit, vorher den richtigen Key auszuwhlen, bleibt leider nur die Kenntnis der IP-Adresse des Initiators. Leider deshalb, weil damit keine dynamische Zuweisung der IP-Adresse an den Initiator mglich ist, denn der Responder muss eine Tabelle mit IP-Adressen und zugehrigen Pre-Shared Keys pflegen. Aber bei der Einwahl bei Internet Service Providern werden grundstzlich die IP-Adressen dynamisch zugewiesen. Mgliche Auswege fr Remote-AccessVPNs bieten die nachfolgend beschriebene Authentifizierung mit digitalen Signaturen oder der IKE Aggressive Mode. Die letzten beiden Nachrichten im IKE Main Mode dienen zur gegenseitigen Authentifizierung von Initiator und Responder. Eine beiderseitige Authentifizierung ist im IKE-Protokoll obligatorisch. Zu diesem Zweck bilden beide Seiten einen geeigneten Hashwert, anhand dessen die Gegenstelle die Identitt des Senders berprfen kann. Als Eingangswerte fr die Hashfunktion dienen die beiden ffentlichen Diffie-Hellmann-Werte (KEi, KEr), der Initiatorund der Responder-Cookie (Ci, Cr), die Daten der Vorschlge des Initiators fr die ISAKMP-Sicherheitsassoziation (SA) und die Identitt des Senders (IDi, IDr):
258
Der IKE Main Mode
HASH_I = HMAC-MD5(SKEYID, KEi + KEr + Ci + Cr + SAi + IDi) HASH_R = HMAC-MD5(SKEYID; KEr + KEi + Cr + Ci + SAi + IDr) Der Initiator erzeugt eine Nachricht, in der er seine Identitt (IDi) und seinen Hashwert (HASH_I) zum Responder schickt, um sich zu authentifizieren. Alles auer dem ISAKMP-Header ist in dieser Nachricht verschlsselt, in unserem Beispiel mit DES, um die Identitt des Initiators zu verbergen. Daraus resultiert auch die Namensgebung (Identity Protection Exchange) dieses Austauschvorgangs. Der Responder authentifiziert sich auf die gleiche Art durch die verschlsselte bermittlung seines Hashwerts (HASH_R) und seiner Identittsinformationen (IDr) an den Initiator.
Initiator Responder
Nachricht 5
Hdr
IDi
HASH_I
Verschlsselt (DES-CBC)
Nachricht 6
Hdr
IDr
HASH_R
Abbildung 8.17: Die Authentifizierung des IKE-Main-Mode-Austauschs erfolgt in den letzten beiden Nachrichten.
Hier wieder ein Praxistipp: Falls es Probleme innerhalb eines Austauschvorgangs gibt, bekommt man oft die Fehlermeldung, dass die Authentifizierung fehlgeschlagen sei. Als Problemquelle vermutet man hier natrlich zuerst den Pre-Shared Key, was in der Regel auch zutrifft. Aber diese Meldung kann auch ein Indiz fr einen Angriff sein. Denn die Authentifizierung in den letzten beiden Nachrichten schlgt auch dann fehl, wenn die anderen Werte wie Cookies, SA-Vorschlag usw. verndert wurden, und nicht nur, wenn der PreShared Key, auf dem SKEYID basiert, nicht identisch ist. Nachdem diese sechs Nachrichten bermittelt und fehlerfrei verarbeitet wurden, besteht eine ISAKMP-Sicherheitsassoziation, unter deren Schutz in der IKE-Phase 2 weitere SAs fr IPSec-Protokolle wie IPSec-ESP oder IPSec-AH erzeugt werden knnen. Dieser Schutz besteht aus Diensten zur Sicherstellung der Nachrichtenintegritt, der Authentizitt und der Vertraulichkeit der bertragenen Daten durch Einsatz der ausgehandelten kryptographischen Verfahren.
259
8.6.2
Authentifizierung mit digitaler Signatur
Eine Authentifizierung mittels einer digitalen Signatur unterscheidet sich innerhalb der ersten beiden Nachrichten im IKE Main Mode nur durch den Inhalt der Vorschlge vom vorhergehenden Beispiel. Hier wird statt der PreShared-Key-Authentifizierung eine mit digitaler Signatur erfolgende ausgehandelt.
Initiator Responder
Hdr SA
Proposal 1 Transf. 1
Nachricht 1 ...... Proposal n Nachricht 2
Transf. n
Hdr SA
Proposal
Transform
Nachricht 3
Hdr KEi Ni [CERT_REQ]
Nachricht 4
Hdr KEr Nr [CERT_REQ]
Nachricht 5
Hdr IDi [Certificate] SIG_I
Nachricht 6
Hdr IDr [Certificate] SIG_R
Abbildung 8.18: Ein IKE-Main-Mode-Austausch mit einer Authentifizierung durch digitale Signaturen
Die beiden Nachrichten zum Schlsseltausch knnen als optionalen Wert eine Anforderung eines digitalen Zertifikats der Gegenstelle (CERT-REQ) enthalten. Falls dies nicht bentigt wird, sind die Nachrichten zwar identisch zu denen der Pre-Shared-Key-Version, aber die Behandlung der bertragenen Werte unterscheidet sich vor der anderer Authentifizierungsmethoden. Der Wert des Hauptschlssels, aus dem sich alle anderen Schlssel ableiten, wird nach folgender Rechenvorschrift ermittelt: SKEYID = HMAC-MD5(Ni + Nr +KE)
260
Der IKE Main Mode
KE ist das Ergebnis des Diffie-Hellman-Verfahrens, also 2xy mod n. Aus diesem Grundwert werden alle weiteren Schlssel auf die in Abschnitt 8.5.5 beschriebene Weise erzeugt. Die letzten beiden Nachrichten, die zur wechselseitigen Authentifizierung von Initiator und Responder dienen, bertragen keinen Hashwert, sondern jeweils eine Signatur der Hashwerte HASH_I und HASH_R. Im Fall von RSA als Signaturalgorithmus wrden die Signaturen aus den Hashwerten wie folgt erzeugt: SIG_I = RSA(Ki_private, HASH_I) SIG_R = RSA(Kr_private, HASH_R) Die privaten Schlssel Ki_private und Kr_private korrespondieren mit deren ffentlichen Schlsseln, die zum Verifizieren der Signatur bentigt werden. Diese Schlssel sind der Gegenstelle entweder bereits bekannt, oder sie werden in einem Zertifikat bertragen, das innerhalb der dritten und vierten Nachricht angefordert werden kann. Im ersten Fall mssen die ffentlichen Schlssel auf eine andere Art und Weise, die ber den Definitionsbereich des IKE-Protokolls hinausgeht, auf den beteiligten Gegenstellen bekannt gemacht werden. Dies kann entweder durch manuelle Schlsselhinterlegung oder etwas moderner und zuverlssiger durch den Einsatz eines Verzeichnisdienstes erfolgen. Dies gilt auch fr Zertifikate: Hier verwendet man eine so genannte PKI (Public Key Infrastructure, vgl. Kapitel 5), die die ntige Infrastruktur zur Verwaltung und Verteilung von digitalen Zertifikaten bereitstellt.
8.6.3
Authentifizierung mit Public-Key-Verschlsselung (RSA)
Diese Art von Verschlsselung benutzt ein asymmetrisches (Public-Key-)Verfahren, das zur Ver- und Entschlsselung unterschiedliche, jedoch einander zugeordnete Schlssel und Algorithmen benutzt. Die beiden Schlssel werden unterschiedlich behandelt; es gibt einen ffentlichen Schlssel und einen privaten Schlssel. Der ffentliche Schlssel (Public Key) darf jedermann bekannt sein, der private (Private Key) hingegen muss vertraulich bleiben und darf niemandem auer seinem Besitzer bekannt sein. Private Schlssel werden in der Regel in verschlsselter Form in speziellen Formaten auf Datentrgern oder Smartcards gespeichert. In Kapitel 4 wurden die asymmetrischen Verschlsselungsverfahren ausfhrlich besprochen. Auch im IKE Main Mode verwendet man ein solches Verfahren zur Authentifizierung des Benutzers. Das Prinzip ist recht einfach: Die Seite, die sich identifizieren mchte, bertrgt ihren mit dem ffentlichen Schlssel der Gegenstelle verschlsselten Nonce- und ID-Wert. Der Empfnger entschlsselt die Daten und verifiziert sie. Dies kann aber niemand sonst nachvollziehen, da nur der Empfnger im Besitz des notwendigen privaten Schlssels ist.
261
Die Art der Authentifizierung wird in den ersten beiden Nachrichten vereinbart. Die Nachrichten zum Schlsseltausch unterscheiden sich wesentlich von denen zur Authentifizierung mit Signaturen oder einem Pre-Shared Key. Eine Vorbedingung dieses Verfahrens ist, dass der Initiator den ffentlichen Schlssel des Responders, den er zum Verschlsseln bentigt, bereits vor dem Austauschvorgang kennt. Ein Austausch von Zertifikaten zu diesem Zweck ist nicht mglich, da diese vorher bertragen werden mssten und damit nicht verschlsselt werden knnen. Damit wre jedoch die Identitt der Teilnehmer an dem Austauschvorgang nicht mehr gewhrleistet, was aber fr diesen Austauschtyp obligatorisch ist. blicherweise werden die ffentlichen Schlssel durch digitale Zertifikate verteilt, da hier eine zuverlssige Bindung der Identitten der Teilnehmer an diesem Verfahren an ihre ffentlichen Schlssel besteht.
Initiator Responder
Hdr SA
Nachricht 1 ...... Proposal n Transf. n Nachricht 2
Hdr SA
Proposal
Transform
Nachricht 3
Hdr KEi
[Hash(Cert)]
IDi
Ni
Verschlsselt (RSA)
Nachricht 4
Hdr KEr
IDr Nr
Verschlsselt (RSA)
Nachricht 5
Hdr HASH_I
Nachricht 6
Hdr HASH_R
Abbildung 8.19: Die Authentifizierung mittels RSA-Public-Key-Verschlsselung im IKE Main Mode
In den Nachrichten zum Schlsseltausch werden also, wie in Abbildung 8.19 zu sehen, neben den ffentlichen Diffie-Hellman-Werten auch der verschlsselte Nonce-Wert und die verschlsselte Identitt des Initiators und in der
262
Der IKE Main Mode
vierten Nachricht umgekehrt auch die des Responders bertragen. Falls der Initiator mehrere ffentliche Schlssel des Responders besitzt, muss der diesem weiterhin mitteilen, welchen er benutzt hat. Dies tut er, indem er einen Hashwert ber das Zertifikat bildet, dessen Schlssel benutzt wurde, und diesen Wert mit zum Responder schickt. Dieser kann anhand des Hashwertes ermitteln, welchen seiner privaten Schlssel er zum Dechiffrieren benutzen muss. Bei der Verschlsselung der Nonce- und Identittswerte werden nur die Nutzdaten verschlsselt. Die Payload-Header mssen unverschlsselt bleiben, um die Art und vor allem die Lnge der Nutzlast bekannt zu machen. Die verschlsselten ID- und Nonce-Nutzdaten, hier durch ein vorangestelltes * gekennzeichnet, werden durch eine RSA-Verschlsselung wie folgt erzeugt: *IDi = RSA(Kr_public, IDi) *Ni = RSA(Kr_public, Ni) *IDr = RSA(Ki_public, IDr) *Nr = RSA(Ki_public, Nr) Die Entschlsselung der Informationen erfolgt mit den korrespondierenden privaten Schlsseln von Initiator und Responder. Die letzten beiden Nachrichten innerhalb dieses Austauschvorgangs tauschen wieder die Hashwerte von Initiator und Responder aus, um eine abschlieende Authentifizierung beider Identitten und des vollstndigen Austauschs vorzunehmen. Dieses Verfahren ist sehr zuverlssig, allerdings zu einem sehr hohen Preis. Denn beide Gegenstellen mssen jeweils vier RSA-Operationen durchfhren, jeweils zwei zum Ver- und zwei weitere zum Entschlsseln. Dies macht diese Art der Authentifizierung sehr rechenintensiv und in der Folge davon sehr langsam. Eine Ver- oder Entschlsselung mit RSA ist etwa 1000fach langsamer als ein symmetrisches Verfahren wie DES. Dies wirft dann Probleme auf, wenn innerhalb einer kurzen Zeitspanne sehr viele ISAKMP-SAs aufgebaut werden mssen, wie es zum Beispiel in Remote-Access-VPNs der Fall ist. Also hat man dieses Verfahren etwas verndert und eine revidierte, schnellere Version der Public-Key-Verschlsselung spezifiziert.
8.6.4
Authentifizierung mit revidierter Public-KeyVerschlsselung (RSA)
Diese Version unterscheidet sich von der vorhergehenden dadurch, dass man einen der Verschlsselungsschritte nicht mit RSA, sondern mit einem symmetrischen Verfahren durchfhrt. Die Menge der in den Schlsseltausch-Nachrichten bertragenen Daten ist dadurch zwar etwas grer, aber die Ausfhrungszeit der notwendigen Berechnungen ist dafr wesentlich krzer geworden.
263
Hier wird, wie in Abbildung 8.20 illustriert, nur der Nonce-Wert mit RSA verschlsselt. Der Rest der Nutzdaten wird mit dem in den ersten beiden Nachrichten ausgehandelten symmetrischen Verfahren verschlsselt, in unserem Fall also mit DES-CBC. Auer der Identitt wird auch noch der ffentliche Diffie-Hellman-Wert verschlsselt, was noch ein hheres Ma an Sicherheit in diesem Verfahren gewhrleistet. Auch hier kann ein Hashwert bertragen werden, um ein bestimmtes Zertifikat zu indizieren, aus dem der benutzte ffentliche Schlssel entnommen wurde. Die Schlssel, die bentigt werden, um den ffentlichen Diffie-Hellman-Wert und den Nonce-Wert von Initiator und Responder zu verschlsseln, wurden aus folgenden Werten berechnet: Kei = HMAC-MD5(Ni + Ci) Ker = HMAC-MD5(Nr + Cr)
Initiator Responder
Hdr SA
Nachricht 1 ...... Proposal n Nachricht 2
Transf. n
Hdr SA
Proposal
Transform
Nachricht 3
Hdr [Hash(Cert)]
Ni
KEi
IDi
[Certificate_i]
RSA
Hdr
Nr KEr
DES-CBC
IDr
Nachricht 4
RSA
Hdr
DES-CBC
HASH_I
Nachricht 5
DES-CBC
Nachricht 6
Hdr HASH_R
DES-CBC
Abbildung 8.20: Die Authentifizierung durch die revidierte Public-Key-Verschlsselung im IKE Main Mode
264
Der IKE Aggressive Mode
Es werden fr beide Richtungen unterschiedliche Schlssel verwendet. Falls ein Verschlsselungsverfahren lngere Schlssel bentigt, als die 128 Bit, die HMAC-MD5 erzeugt, dann erfolgt so lange eine Verkettung des Hashwertes nach folgender Regel, bis die notwendige Gesamtlnge erreicht wurde: K = K1 + K2 +....+Kn Die bentigten Teilschlssel K1 bis Kn werden wie folgt berechnet: K1 = HMAC-MD5(Kei + Ni + 0x00) K2 = HMAC-MD5(Kei + K1) ...... Kn = HMAC-MD5(Kei + Kn-1) Die zu bertragenden, mit DES verschlsselten ID- und KE-Nutzdaten, hier durch ein vorangestelltes* gekennzeichnet, werden auf folgende Weise erzeugt: *IDi = DES(Kei, IDi) *IDr = DES(Ker, IDr) *KEi = DES(Kei, KEi) *KEr = DES(Ker, KEr) Da DES blicherweise im CBC-Modus betrieben wird, werden hierfr Initialisierungsvektoren (IV) bentigt. Der erste IV besitzt den Wert 0x0000000000000000, die nachfolgenden erhalten den Wert des Chiffretextes der jeweils vorhergehenden Verschlsselung. Die beiden letzten Nachrichten in diesem Austausch fhren wieder die abschlieende Authentifizierung durch die Hashwerte von Initiator und Responder durch.
8.7
Der IKE Aggressive Mode ist eine Instanziierung des ISAKMP Aggressive Exchange, der den Aufbau einer ISAKMP-Sicherheitsassoziation mit nur drei Nachrichten ermglicht. Aufgrund der Struktur dieses Austauschvorgangs muss die IP-Adresse des Initiators nicht vorher bekannt sein und kann somit auch, zum Beispiel bei der Einwahl bei einem Internet Service Provider, dynamisch zugewiesen werden. Das Prinzip des IKE Aggressive Mode ist es, so viel an Informationen in die Nachrichten hineinzupacken, wie es zum gegebenen Zeitpunkt mglich ist. Allerdings hat dies auch seinen Preis, der hier in Form einer etwas reduzier-
265
ten Sicherheit gegen bestimmte Arten von Denial-of-Service-Angriffen in Erscheinung tritt. Der Grund besteht darin, dass bereits vor dem Umlauf der Cookies sehr rechenintensive Prozesse stattfinden. Weiterhin ist die Identitt des Initiators bei einer Authentifizierung mittels Pre-Shared Key nicht geschtzt, da dieser seine Identittsinformationen bereits in die erste, noch unverschlsselte Nachricht einfgt. Dies birgt andererseits den Vorteil, dass die IP-Adresse des Initiators nicht statisch sein muss. Die Aushandlungsmglichkeiten sind ebenfalls etwas eingeschrnkt, da in der ersten Nachricht bereits Werte bertragen werden, die bestimmte Voraussetzungen bedingen, die im Main Mode noch aushandelbar wren. Zum Beispiel wird der ffentliche Diffie-Hellman-Wert des Initiators bereits in der ersten Nachricht bermittelt. Also muss sich der Initiator schon zu diesem Zeitpunkt fr eine Oakley-Gruppe entschieden haben und kann nicht mehr verschiedene Vorschlge mit verschiedenen Gruppen machen.
Initiator Responder
Hdr SA
Nachricht 1 Prop.1 Transf. 1 Prop.n Transf. n KEi Ni IDi Nachricht 2
Hdr SA Proposal Transform KEr
Nr
IDr
HASH_R
Nachricht 3
Hdr
HASH_I
Abbildung 8.21: Der IKE Aggressive Mode mit Pre-Shared-Key-Authentifizierung
In praktischen Implementierungen, also zum Beispiel in einem RemoteAccess-VPN, in dem der IKE Aggressive Mode blicherweise verwendet wird, ist diese Einschrnkung jedoch nicht so einschneidend. Denn in solch einem abgeschlossenen Netz mit einer bergreifenden Sicherheitsstrategie und der Kenntnis der technischen Mglichkeiten der eingesetzten Systeme kennt der Initiator bereits die Sicherheitsstrategie und kann dem Responder ein relativ kurzes Proposal unterbreiten. Er muss nicht alle mglichen Kombinationen und Optionen dort hineinpacken, sondern kann ganz wenige, unter Umstnden vielleicht sogar nur einen einzigen Vorschlag machen, von dem er wei, dass ihn der Responder annimmt.
266
Ein anderes Szenario ist ein Extranet-VPN. Da hier oft Gerte verschiedener Hersteller in verschiedenen Firmen mit unterschiedlichen Sicherheitsstrategien eine ISAKMP-Sicherheitsassoziation aufbauen sollen, sind die Auswahlmglichkeiten in der Regel reichhaltiger. Allerdings arbeiten solche Verbindungen meist zwischen IPSec-Security-Gateways, die eine feste IP-Adresse besitzen und somit im flexibleren IKE Main Mode arbeiten knnen.
8.7.1
Authentifizierung mit Pre-Shared-Secret
In unserem Beispiel in Abbildung 8.22 sehen Sie den Aufbau einer ISAKMPSicherheitsassoziation im IKE Aggressive Mode. Die Authentifizierung erfolgt durch Pre-Shared Secrets. In der ersten Nachricht schickt der Initiator der ISAKMP-Sicherheitsassoziation seine Vorschlge (SAi), seinen ffentlichen Diffie-Hellman-Wert (KEi), seinen Nonce-Wert (Ni) und seine Identittsinformationen (IDi) zum Responder. Diese Nachricht ist unverschlsselt und enthlt im ISAKMP-Header nur das Initiator-Cookie. Somit muss der Responder mit seinen Berechnungen fr den Schlsseltausch beginnen, bevor er sein eigenes Cookie zurckbekommen hat. Er wei somit noch nicht sicher, ob er auch tatschlich mit dem Initiator kommuniziert.
Initiator Responder
Nachricht 1 Hdr SA Prop.1 Transf. 1 ...... KEi Ni Nachricht 2
IDi
[Cert_Req]
Hdr SA Pro/Trans KEr Nr IDr [Cert_Req] [Cert] SIG_R
Nachricht 3
Hdr
[Cert]
SIG_I
Abbildung 8.22: Der IKE Aggressive Mode mit Signatur-Authentifizierung
Der Responder sucht nun aufgrund der ID-Informationen des Initiators den zugehrigen Pre-Shared Key aus seiner Datenbank und berechnet ber das Diffie-Hellman-Verfahren seinen Hauptschlssel (SKEYID) und alle weiteren, notwendigen Schlssel. Deren Berechnung erfolgt in der gleichen Weise wie im IKE Main Mode.
267
Initiator
Responder
Hdr SA Prop.1 Transf.1
Nachricht 1 ...... [Hash(Cert)]
KEi
IDi Ni
(RSA)
Nachricht 2
Hdr SA Prop.1/Trans. KEr
IDr Nr
HASH_R
(RSA)
Nachricht 3
Hdr
HASH_I
Abbildung 8.23: Der IKE Aggressive Mode mit Public-Key-Authentifizierung
Der Responder berechnet auerdem seinen ffentlichen Diffie-Hellman-Wert und hat damit gengend Informationen, um seinen Hashwert HASH_R zu berechnen. Diesen Hashwert bertrgt er zusammen mit seinem ffentlichen Diffie-Hellman-Wert (KEr), dem von ihm ausgewhlten Vorschlag (SAr), seinem Nonce-Wert (Nr) und seiner Identittsinformation (IDr) zum Initiator. Dieses Paket ist ebenfalls noch unverschlsselt, enthlt jetzt aber beide Cookies. Der Initiator kann nun sein Cookie verifizieren und anschlieend seine Berechnungen vornehmen, um die erforderlichen Schlssel zu erzeugen. Nachdem dies geschehen ist, erzeugt der Initiator seinen Hashwert HASH_I und bertrgt ihn in der dritten und letzten Nachricht des IKE-AggressiveMode-Austauschs zum Responder. Diese Nachricht ist verschlsselt, und das Cookie des Responders ist jetzt auch einmal umgelaufen. Er kann es auswerten und anschlieend den erhaltenen Hashwert berprfen, um den Initiator und den Austauschvorgang zu authentifizieren.
Initiator Responder
Nachricht 1
Hdr SA Prop.1 Tran.1 ...... [Hash(Cert)] Ni KEi IDi [Cert]
RSA
DES-CBC
HASH_R
Nachricht 2
Hdr SA Prop.1/Trans. Nr
RSA
KEr
IDr
DES-CBC
Nachricht 3
Hdr
HASH_I
Abbildung 8.24: Der IKE Aggressive Mode mit revidierter Public-Key-Authentifizierung
268
Der IKE Quick Mode
8.7.2
Authentifizierung mit digitaler Signatur
Auch hier werden nur drei Nachrichten bentigt, in denen alle bentigten Datenstrukturen enthalten sind. Der Unterschied zur Authentifizierung mit einem Pre-Shared Key besteht auch im Aggressive Mode darin, dass statt der Hashwerte HASH_I und HASH_R die digitalen Signaturen dieser Hashwerte bertragen werden. Optional knnen noch digitale Zertifikate bertragen werden. Auch hier gelten alle Einschrnkungen wie im vorangegangenen Beispiel, insbesondere die, dass die Identitten nicht verborgen sind und eine gewisse Gefahr durch Denial-of-Service-Angriffe besteht.
8.7.3
Authentifizierung mit standardisierter und revidierter Public-Key-Verschlsselung
Die generelle Funktionsweise der Authentifizierung entspricht der im IKE Main Mode. Auch hier werden so viele Daten wie mglich in die Nachrichten gepackt. Hier werden auch nur drei UDP-Pakete zwischen Initiator und Responder ausgetauscht, um eine ISAKMP-Sicherheitsassoziation aufzubauen. Diese Art der Authentifizierung hat gegenber den beiden vorher beschriebenen den groen Vorteil, auch im IKE Aggressive Mode die Identitt der beteiligten Gegenstellen zu verbergen. Denn die Identittsinformationen werden mit dem ffentlichen Schlssel der jeweiligen Gegenstelle verschlsselt und erst dann bertragen. Die Angriffspunkte fr Denial-of-Service-Angriffe bleiben jedoch bestehen, weil vollstndige Cookie-Umlufe bis zur Berechnung der Diffie-Hellman-Funktion nicht mglich sind. Auch mit der genderten Methode der Public-Key-Verschlsselung werden die Identitt von Initiator und Responder geschtzt, indem sie verschlsselt bertragen werden. Die Berechnung der Schlssel und die Verschlsselung selbst erfolgen auf die gleiche Art wie im IKE Main Mode, wodurch eine insgesamt hhere Verarbeitungsgeschwindigkeit ermglicht wird.
8.8
Der IKE Quick Mode
Der IKE Quick Mode basiert auf keinem ISAKMP-Austauschtyp, sondern existiert nur im IKE-Protokoll und ist immer an einen vorangegangenen Phase-1-Austausch gebunden. Mit dem Quick Mode, der nur in der IKEPhase 2, also unter dem Schutz einer in Phase 1 erzeugten ISAKMP-SA, mglich ist, werden die Sicherheitsassoziationen von IPSec oder anderen Sicherheitsprotokollen ausgehandelt. Innerhalb einer ISAKMP-SA knnen mehrere IPSec-SAs erzeugt werden. Es knnen auch innerhalb eines Quick-ModeAustauschvorgangs gleichzeitig mehrere SAs erzeugt werden.
269
Da durch die ISAKMP-SA bereits Dienste zur Integrittsprfung, Authentifizierung und Sicherstellung der Vertraulichkeit zur Verfgung stehen, kann der Austausch durch nur insgesamt drei Nachrichten erfolgen. Es werden im Weiteren auch die Identitten der Gegenstellen als gegeben angesehen, die sich in Phase 1 gegenseitig authentifiziert haben. Der Quick Mode erzeugt eine Sicherheitsassoziation fr nachfolgende Sicherheitsprotokolle und benutzt daher hnliche Mechanismen, wie es die ISAKMP-Austauschvorgnge in der Phase 1 tun. Auch hier werden Nonce-Werte erzeugt und ausgetauscht, um sich einerseits vor Angriffen durch wiederholtes Senden von Nachrichten zu schtzen und andererseits neue Zufallswerte zur Generierung von Schlsselmaterial zu erhalten. Zu diesem Zweck kann optional, falls die Sicherheitsstrategie dies vorschreibt, ein Austausch von neu erzeugten ffentlichen Diffie-Hellman-Werten stattfinden. Alle Pakete in Phase 2 werden verschlsselt bertragen. Im ersten Paket des Initiators in unserem Beispiel, in dem eine IPSec-ESP-Sicherheitsassoziation mit Triple-DES und HMAC-MD5-96 erzeugt werden soll, mssen der Vorschlag (SA), der Nonce-Wert und der HASH_1 enthalten sein. Optional knnen noch Client-IDs (IDc) und im Fall von Perfect Forwarding Secrecy (PFS) der ffentliche Diffie-Hellman-Wert (KEi) bertragen werden.
Initiator Responder
Nachricht 1
Hdr
HASH_1
SA
Ni
KEi
IDi
IDr
Verschlsselt
Nachricht 2
Hdr
HASH_2
SA
Nr
KEr
IDi
IDr
Verschlsselt
Nachricht 3
Hdr
HASH_3
Verschlsselt
Abbildung 8.25: Der IKE-Quick-Mode-Austausch erfolgt unter dem Schutz der ISAKMP-SA.
Der Hashwert HASH_1 wird auf folgende Weise ermittelt: HASH_1 = HMAC-MD5(SKEYID_a + MID + SA + Ni [+ KEi [+ Idci + IDcr]]) Die HMAC-Version des in Phase 1 bereits ausgehandelten MD5-Hashverfahrens wird als Pseudo Random Function (PRF) zum Erzeugen der Hashwerte benutzt. MID ist hierbei die Message ID aus dem ISAKMP-Header; die optio-
270
Der IKE Quick Mode
nalen Parameter sind in eckige Klammern gesetzt. Der Hashwert muss in jedem Paket unmittelbar auf den ISAKMP-Header folgen, und die SA-Nutzdaten in den ersten beiden Nachrichten mssen nach dem Hashwert eingefgt werden. Die Reihenfolge der restlichen Nutzdaten ist optional, mit Ausnahme der Client-IDs, die am Ende einer Nachricht stehen. Diese Client-IDs werden dann benutzt, wenn fr einen anderen Initiator und Responder, als den in Phase 1 beteiligten, ein Quick-Mode-Austausch erfolgt. Der Responder verarbeitet die eingegangene Nachricht und konstruiert, falls kein Fehler aufgetreten ist und er einen Vorschlag des Initiators akzeptabel findet, die zweite Nachricht dieses Austauschvorgangs. Der Hashwert HASH_2 dieser Nachricht wird, je nach Nutzdaten, wie folgt erzeugt: HASH_2 = HMAC-MD5(SKEYID_a + MID + Ni + SA + Nr [+ KEr [+ IDcr]]) Auch hier kann im Falle von PFS optional der ffentliche Diffie-Hellman-Wert mit bertragen werden. Der Initiator verarbeitet die Nachricht und erzeugt die dritte und letzte Nachricht dieses Austauschvorgangs, in der nur der HASH_3 enthalten ist. Dieser Hashwert wird aus den folgenden Werten erzeugt: HASH_3 = HMAC-MD5(SKEYID_a + 0x00 + MID + Ni + Nr) Nachdem der Responder die Nachricht verarbeitet und den Hashwert berprft hat, ist der Quick-Mode-Austausch abgeschlossen. Der Quick Mode berechnet auch die fr die erzeugte IPSec-Sicherheitsassoziation bentigten Schlssel. In unserem Beispiel wurde das IPSec-ESP-Protokoll ausgehandelt, mit HMAC-MD5-96 und Triple-DES als Funktionen zur Authentifizierung und Verschlsselung. Insgesamt werden hierfr 320 Bit an Schlsselmaterial bentigt. Diese 320 Bits bestehen aus 128 Bit fr HMACMD5-96 und drei mal 64 Bit fr Triple-DES. Beachten Sie, dass der Triple-DESAlgorithmus seine drei 56-Bit-Schlssel aus den drei 64-Bit-Strings dadurch erzeugt, dass er jedes achte Bit daraus entfernt. Der in diesem Beispiel bentigte Grundschlssel KEYMAT kann, je nachdem, ob PFS gefordert ist, auf zwei verschiedene Arten erzeugt werden. Im Fall von PFS wurden im Quick Mode ffentliche Diffie-Hellman-Werte zwischen Initiator und Responder ausgetauscht, die mit in die Berechnung einflieen. Aus diesen beiden Werten und ihrem privaten, geheimen Wert berechnen beide Seiten den identischen Wert KE als Ergebnis des Diffie-Hellman-Verfahrens. Der Grundschlssel mit PFS wird wie folgt berechnet: KEYMAT = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) Die Werte fr das Protokoll, in unsrem Fall IPSec-ESP, und den Security Parameter Index (SPI) stammen aus dem Paket, in dem der Vorschlag fr die Sicherheitsassoziation ausgewhlt wurde.
271
Das Ergebnis der HMAC-MD5-Funktion ist aber nur 128 Bit lang, also muss das bentigte 320 Bit lange Schlsselmaterial (K) durch Verkettung dieses Wertes erzeugt werden: K = K1 + K2 + K3 mit K1 = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + KE + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + KE + Protokoll + SPI + Ni + Nr) Falls keine Perfect Forwarding Secrecy bentigt wird, erzeugt IKE den Grundschlssel aus dem dafr vorgesehenen Grundschlssel (SKEYID_d) der ISAKMP-Sicherheitsassoziation und den Nonce-Werten des vorliegenden Quick-Mode-Austauschs: KEYMAT = HMAC-MD5(SKEYID_d + Protokoll + SPI + Ni + Nr) Das Ergebnis der HMAC-MD5-Funktion ist auch in diesem Fall nur 128 Bit lang, also erfolgt wieder eine Verkettung: K = K1 + K2 + K3 mit K1 = HMAC-MD5(SKEYID_d + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + Protokoll + SPI + Ni + Nr) Aus diesen 384 Bit werden fr das IPSec-ESP-Protokoll die ersten 192 Bit fr Triple-DES und die folgenden 128 Bit fr den HMAC-MD5-Algorithmus verwendet; der Rest bleibt ungenutzt.
8.9
Die Performance von IKE
Wie in den vorangegangenen Abschnitten deutlich wurde, werden in IKE eine ganze Reihe teilweise recht aufwendiger Rechenoperationen durchgefhrt. Ihre Anzahl und Art richten sich ausschlielich nach der verwendeten Sicherheitsstrategie. So ist zum Beispiel der Aufbau einer IPSec-Sicherheitsassoziation unter Verwendung von Public-Key-Verfahren zur Authentifizierung und Perfect Forwarding Secrecy sehr aufwendig und langwierig zu berechnen, whrend der gleiche Vorgang mit einer Pre-Shared-Key-Authentifizierung ohne PFS um ein Vielfaches schneller ist. Man muss sich immer vor Augen halten, in welchen Dimensionen hier gerechnet wird. Asymmetrische (Public-Key-)Verfahren wie Diffie-Hellman oder RSA erzeugen und rechnen mit Primzahlen in Bereichen von 768 oder 1024 Bit, fhren Berechnungen mit Exponenten im Bereich von 180 Dezimal-
272
stellen durch oder dividieren durch 1024 Bit groe Primzahlen. Solche Operationen, die zudem nicht mit voller Untersttzung von numerischen Coprozessoren auf Basis Gleitkomma-Arithmetik durchgefhrt werden knnen, verschlingen eine immense CPU-Zeit und auch einiges an Speicher fr ihre Zwischenergebnisse. Auf Security-Gateways, die verschiedene Netze miteinander verbinden, fllt IKE nicht so sehr ins Gewicht, da es nur relativ selten aktiv ist und wenige SAs erzeugt und verwaltet. Hier kann man auch bedenkenlos die Intervalle fr eine neue Schlsselgenerierung auf kurze Werte oder bertragene Datenvolumina, z.B. 100 Mbyte oder 1 Gbyte, setzen und generell mit Perfect Forwarding Secrecy arbeiten. Im Fall von Remote-Access-VPNs sieht die Sache allerdings schon ganz anders aus, denn hier mssen oft in relativ kurzen Zeitspannen sehr viele Sicherheitsassoziationen erzeugt werden pro Benutzer werden ja mindestens eine ISAKMP-SA und zwei unidirektionale IPSec-SAs erzeugt. Bei solchen Abschtzungen muss man ebenfalls bercksichtigen, dass solche Anmeldevorgnge auch bereits bestehende Verbindungen beeinflussen, indem sie die dort bentigten Ressourcen abziehen. Der magische Wert fr Remote-Access-VPN-Konzentratoren, ber den sich fast alle Hersteller leider beharrlich totschweigen, ist denn auch nicht so sehr der Datendurchsatz als solcher, sondern die Angabe, wie viele Anmeldungen pro Minute erfolgen knnen. Interessant ist in diesem Zusammenhang auch die etwas ketzerische Frage, ob whrend dieser Zeitspanne die 1000 vielleicht bereits angemeldeten Benutzer berhaupt noch Daten bertragen knnen oder ob der VPN-Konzentrator nur noch mit IKE-Funktionen beschftigt ist.
8.9.1
IKE und Hardwarebeschleuniger
Der Datendurchsatz ist natrlich auch ein wichtiger Faktor, aber er ist durch den Hersteller am leichtesten in den Griff zu bekommen. Meist setzt man Beschleunigerhardware ein, die die symmetrischen und die Hashverfahren auf speziellen Chips abarbeitet. Fr Public-Key-Verfahren gibt es leider nur ganz wenige Chipstze, und diese besitzen oft auch nicht den Beschleunigungsfaktor von Chips zur Verarbeitung von symmetrischen Algorithmen. Also werden in sehr vielen Systemen, auch solchen mit Hardwareverschlsselung, gerade die rechenintensiven Public-Key-Verfahren immer noch per Software implementiert. An dieser Stelle ein Tipp, falls Sie vor der Auswahl oder Beurteilung von Hardware- gegenber Softwareverschlsselung stehen: Sehr oft wird damit geworben, dass Hardwareverschlsselung schneller als deren Softwarevariante sei. Dies stimmt nicht immer, es ist zwar sehr oft der Fall, insbesondere bei Algorithmen wie DES, die bereits als Hardwareverfahren entwickelt wurden, aber eben nicht immer. Algorithmen, die speziell zur Implementierung
273
in Software entworfen und optimiert worden sind, knnen unter Umstnden sogar an Performance einben, da die Verwaltung der Beschleunigerkarten durch das System sowie die Prozess- und die Datenverteilung eine gewisse Zusatzlast erzeugen. Man muss weiterhin sehr genau untersuchen, welche Protokolle die Hardware berhaupt untersttzt. Je grer die Protokollvielfalt, desto besser. Was aber auf alle Flle untersttzt werden sollte, ist eine Hardware-Datenkompression, da die Kompression auf den Schichten unterhalb von IPSec sinnlos ist, da verschlsselte Daten nicht mehr komprimiert werden knnen. Es sollte im Idealfall auch mglich sein, die Performance eines VPN-Konzentrators durch den Einsatz von mehreren, parallel betriebenen Hardwarebeschleunigern skalieren zu knnen. Die ideale Hardware wrde RSA, Diffie-Hellman, DES, Triple-DES, MD5, SHA1 und IPSec-Kompression mit entsprechenden Chipstzen untersttzen, so dass das Muttersystem die rechenintensiven Prozesse auf die Karten auslagern kann. Insbesondere fr IKE sollten Diffie-Hellman und RSA durch spezielle Chipstze bearbeitet werden knnen, ansonsten bringt eine Beschleunigerkarte keinen nennenswerten Performance-Gewinn. Ein kleines Beispiel soll verdeutlichen, welche Leistungssteigerung gute Beschleuniger-Chips bringen knnen. Die kalifornische Firma Hi/fn stellt verschiedene Chips her, die speziell zum Beschleunigen von kryptographischen Algorithmen entwickelt wurden. Zum Vergleich nehmen wir zwei Chips dieser Firma. Einer davon, der Hi/fn 6500, besitzt ein spezielles Maskendesign zur Beschleunigung von modularer Arithmetik. Der andere Chip, der Hi/fn 7901, ist ein spezieller Beschleuniger fr symmetrische Verfahren, der nur eine normale Integer-CPU fr Public-Key-Verfahren eingebaut hat.
Hi/fn 7901, Integer-CPU Pre-Shared Key Digitale Signatur 6 IKE-SA/Sekunde 1,5 IKE-SA/Sekunde Hi/fn 6500, Public-Key-ASIC 300 IKE-SA/Sekunde 115 IKE-SA/Sekunde
Tab. 8.1: Vergleich zwischen Integer-CPU und ASIC-Design zur Beschleunigung von PublicKey-Arithmetik
Zum Vergleich habe ich zwei verschiedene IKE-Aushandlungen herangezogen, einmal eine Authentifizierung mit Pre-Shared Key, die zwei Public-KeyBerechnungen (Diffie-Hellmann, 1024 Bit) bentigt, und zum anderen eine Authentifizierung mit digitaler Signatur. Der zweite Fall ist wesentlich aufwendiger. Er bentigt pro Gegenstelle zwei 1024-Bit-Diffie-Hellman-Berechnungen (Oakley-Gruppe.2), eine 1024-Bit-RSA-Verschlsselung und zwei 1024-Bit-RSA-Entschlsselungen.
274
Man kann sehr gut erkennen, wie gro der Unterschied zwischen einer normalen Integer-CPU und einem speziellen Maskendesign fr bestimmte Public-Key-Algorithmen ist. Falls Sie vor der Auswahl von Hardwarebeschleunigern stehen, sollten Sie sich sehr genau darber informieren, wie die Karte und die verwendeten Chips aufgebaut sind, ansonsten knnen Sie leicht unangenehme berraschungen erleben. Als sehr sinnvoll erweisen sich Designs mit getrennten Chips fr symmetrische und asymmetrische Verfahren oder neue Super-Chips, die beide Methoden in Form eines entsprechenden Maskendesigns untersttzen.
275
Das Layer 2 Tunneling Protocol
Das Layer 2 Tunneling Protocol (L2TP) unterscheidet sich grundstzlich von IPSec. IPSec ist primr ein Sicherheitsprotokoll auf IP-Ebene mit der Option, IP-Pakete zu tunneln. L2TP hingegen ist ein reines Tunneling-Protokoll auf PPP-Ebene, das auch andere Protokolle als nur IP einkapseln kann. Das Layer 2 Tunneling Protocol wurde entwickelt, um PPP (Point-to-Point Protocol, ein Verfahren zum Transport von Netzwerkprotokollen ber Punktzu-Punkt-Verbindungen) die Datenkommunikation ber andere als Punktzu-Punkt-Verbindungen zu ermglichen. Sein vorrangiges, aber nicht ausschlieliches Einsatzgebiet ist daher der virtuelle Remote Access ber Whlverbindungen und ein IP-Netzwerk. L2TP ist als Verbesserung und Weiterentwicklung zweier lterer, nicht standardisierter Verfahren, des Point-to-Point Tunneling Protocol (PPTP) und des Layer 2 Forwarding (L2F), zu verstehen. Die generelle Struktur und die jeweiligen Vorteile beider Verfahren wurden in das Layer 2 Tunneling Protocol, das im RFC 2661 beschrieben ist, bernommen. Obwohl sowohl PPTP als auch L2F heute noch in bestehenden Installationen verwendet werden, findet keine Weiterentwicklung der beiden Verfahren mehr statt, und in neuen Projekten wird zunehmend L2TP als Tunnelingverfahren und IPSec als Sicherheitsprotokoll eingesetzt.
9.1
Das Point-to-Point Protocol (PPP)
Um L2TP richtig verstehen zu knnen, muss man auch die Arbeitsweise von PPP verstehen. Das Point-to-Point Protocol wurde entwickelt, um verschiedenste Netzwerkprotokolle wie IP, IPX, Appletalk usw. ber eine Punkt-zuPunkt-Verbindung zu bertragen. Derartige Verbindungen kommen bei leitungsvermittelnden Netzen oder Festverbindungen vor. Vor der Entwicklung von PPP wurden diese Verbindungen mit proprietren, meist auf Basis von HDLC (High-Level Data Link Control) arbeitenden Verfahren betrieben. PPP ermglichte erstmals Punkt-zu-Punkt-Verbindungen auch zwischen Produkten verschiedener Hersteller. Mittlerweile ist dieses Protokoll in praktisch jedem Router und jedem Rechner (z.B. Microsoft DF-Netzwerk, Unix-pppd) implementiert. Der Zugriff auf das Internet ber Whlverbindungen, den die Internet Service Provider (ISP) weltweit anbieten, basiert fast ausschlielich auf PPP; auch bei Festverbindungen niedriger Bandbreite wird es im ISPUmfeld sehr oft benutzt.
277
9 Das Layer 2 Tunneling Protocol
9.1.1
PPP-Remote-Access
In Abbildung 9.1 sehen Sie ein typisches Unternehmensszenario fr einen Remote Access, in dem sich ein Rechner per Whlverbindung ber einem Remote Access Concentrator (RAC) Zugriff auf ein Intranet verschafft. Sowohl im PC als auch im RAC bernimmt das PPP-Protokoll die Aufgabe, diese Punkt-zu-Punkt-Verbindung zu initialisieren, aufrechtzuerhalten und zu beenden. In PPP sind alle Gegenstellen (Peers) gleichwertig, es gibt weder eine dedizierte Server- oder Clientfunktionalitt noch ein rollenbasierendes Verhalten wie Initiator oder Terminator. Es ist auch nicht unbedingt notwendig, dass die PPP-Gegenstellen immer den gleichen Funktionsumfang untersttzen. Die Kommunikationsoptionen und -parameter knnen whrend der Initialisierungsphase untereinander ausgehandelt werden. Lediglich wenn bestimmte Funktionen von einer Seite als zwingend erforderlich angesehen werden und die Gegenstelle diese nicht in ausreichend erscheinendem Mae untersttzen kann, wird ein Verbindungsaufbau abgebrochen. Dies ist aber nur in ganz wenigen Fllen gegeben, zum Beispiel dann, wenn eine Seite Datenverschlsselung auf PPP-Ebene mchte und die andere dies nicht kann.
Rechnermit DF-Client
Whlverbindung
Remote Access Concentrator (RAC)
ISDN PSTN GSM
Point-to-Point Protocol (PPP)

Abbildung 9.1: Remote Access mit PPP ber Whlverbindungen
9.1.2
PPP-Komponenten
PPP basiert auf dem HDLC-Protokoll, allerdings nur insoweit, als es dessen Rahmenstruktur benutzt. Die HDLC-Adressierung wird nicht benutzt, da nur zwischen zwei Endpunkten kommuniziert wird. Die Adressfelder dienen nur zur Identifikation von PPP-Rahmen, indem dort feste, definierte Werte eingesetzt werden. PPP kann man in Abhngigkeit von ihrer Funktion in verschiedene, in der PPP-Terminologie als Sublayer bezeichnete Schichten untergliedern. Wie Sie in Abbildung 9.2 sehen, gibt es fr jede dieser Funktionen in den verschiedenen Schichten Steuerprotokolle zur Aushandlung und Konfiguration dieser Dienste und die implementierten Dienste selbst, die die zu bertragenden Pakete entsprechend umformen oder Prozeduren wie die Authentifizierung durchfhren.
278
Intranet
Die Multiplex-Schicht In dieser Schicht konfigurieren die Steuerprotokolle die sptere Behandlung und den Transport von Paketen der zu bertragenden Netzwerkprotokolle (wie IP oder IPX). Dies betrifft die Bekanntgabe oder Zuweisung von Netzwerkadressen, die bermittlung notwendiger Parameter fr bestimmte Protokolle usw. Die beiden wichtigsten Protokolle sind das IPCP (IP Control Protocol) und das IPXCP (IPX Control Protocol). PPP ermglicht die bertragung einer ganzen Reihe weiterer Netzwerkprotokolle, jedoch hat sich IP derart stark durchgesetzt, dass diese praktisch keine Rolle mehr spielen.
Steuerungsprotokoll IPCP IPXCP CCP Auth. ECP
Verarbeitung Multiplex-Schicht - Netzwerkprotokoll-Verteilung Dienste-Schicht - Kompression - CHAP, PAP - Verschlsselung Medienabhngige Schicht - HDLC-Adressierung - Framing, Escaping - Frame Check Sequence (FCS)
LCP
Abbildung 9.2: Die verschiedenen Verarbeitungsschichten in PPP
In der Datenphase wird in dieser Schicht das Multiplexen und Demultiplexen der Netzwerkpakete vorgenommen. Da PPP die gleichzeitige bertragung verschiedener Protokolle ermglicht, mssen ausgehende Pakete gekapselt und gekennzeichnet werden. Ankommende Pakete mssen aufgrund der Kennzeichnungen in den PPP-Frames zur korrekten Weiterverarbeitung in den richtigen Netzwerk-Stack geleitet werden. Die Dienste-Schicht In diesem Bereich werden Dienste angesiedelt, die die zu bertragenden Daten umformen oder Funktionen wie die Authentifizierung durchfhren. blicherweise sind im PPP die Authentifizierungsprotokolle PAP und CHAP verfgbar; mittlerweile bietet das EAP (Extensible Authentication Protocol)
279
auch weiter reichende Funktionen und die Mglichkeit, herstellerspezifische Verfahren einzubinden. Weitere Dienste sind die Datenkompression und in manchen, seltenen Fllen auch die Datenverschlsselung. Entsprechende Steuerprotokolle handeln zwischen den PPP-Gegenstellen die notwendigen Optionen und Parameter aus. Als wichtigstes Protokoll in diesem Bereich ist das CCP (Compression Control Protocol) zu nennen, das die Datenkomprimierung steuert und damit Bandbreite und dadurch bertragungskosten einsparen kann. Die medienabhngige Schicht Hier spielt als Steuerprotokoll das LCP (Link Control Protocol) die Hauptrolle. Sobald ber eine Punkt-zu-Punkt-Verbindung eine PPP-Session gestartet wird, erwacht das LCP zum Leben und konfiguriert das Verhalten der Gegenstellen. LCP definiert bestimmte Dienste, wie zum Beispiel die Authentifizierung, die in der Dienste-Schicht angesiedelt sind. Somit erstreckt sich der Wirkungsbereich des Link Control Protocol ber die Grenzen der medienabhngigen Schicht hinaus. Die Dienste in dieser Schicht bernehmen die Konstruktion von PPP-Frames, die Berechnung von Prfsummen und alles andere, was notwendig ist, um ein PPP-Paket an die darunter liegende bertragungsschicht weiterzuleiten.
9.1.3
PPP-Steuerungsprotokolle und -Dienste
Die Steuerprotokolle haben eine zentrale Bedeutung, denn sie handeln die gewnschten Dienste zwischen zwei PPP-Gegenstellen aus und konfigurieren sie anschlieend auch interaktiv. Man unterscheidet dabei grundstzlich zwischen Link-, Dienst- und Netzwerksteuerprotokollen, je nachdem auf welcher Ebene sie angesiedelt sind. Im Folgenden werden einige wichtige und in praktisch allen PPP-Implementierungen vorhandene Protokolle erlutert: Das Link Control Protocol (LCP) Das Password Authentication Protocol (PAP) Das Challenge Handshake Authentication Protocol (CHAP) Das Compression Control Protocol (CCP) Das IP Control Protocol (IPCP) Das Link Control Protocol (LCP) Das LCP (Link Control Protocol) ist das Protokoll, das immer in der Startphase jeder PPP-Verbindung ausgefhrt wird. Es legt die eigentlichen, medienabhngigen Parameter fest und handelt anschlieend die im Weiteren auszufhrenden Steuerprotokolle und Dienste aus. Dies sind in der Praxis Authenti-
280
fizierungsverfahren, Datenkompression und Netzwerksteuerprotokolle zur Konfiguration der bertragung von IP, IPX usw. ber die PPP-Verbindung. Diese Konfiguration wird in Form einer Reihe von Anfragen, Antworten, nderungsvorschlgen oder Ablehnungen durchgefhrt. Dieser Vorgang kann auch asynchron erfolgen; eine Gegenstelle wartet mit ihrer nchsten Anfrage nicht, bis ihre vorherige beantwortet ist. In einer Anfrage knnen auch mehrere Optionen enthalten sein. Im PPP-Standard sind Configure Request (REQ), Configure Acknowledge (ACK), Configure Negative Acknowledge (NAK) und Configure Reject (REJ) als LCP-Botschaften zwischen PPP-Peers spezifiziert. Das Password Authentication Protocol (PAP) PAP ist ein relativ einfach aufgebautes Authentifizierungsprotokoll. Es wird von der zeitlichen Abfolge her zwischen der LCP- und der NCP-Phase ausgefhrt und entscheidet, ob eine Verbindung weiter aufgebaut oder unmittelbar beendet wird. Es ist in einem eigenen Standard, dem RFC1334, beschrieben. Die Authentifizierung erfolgt, indem die Seite, die ihre Identitt nachweisen muss, der Gegenstelle einen Authenticate Request schickt, in dem die Peer-ID (blicherweise der Benutzername) und ein Passwort im Klartext enthalten sind. Die Gegenstelle berprft das Passwort und schickt, falls es richtig ist, ein Authenticate Acknowledge, ansonsten ein Authenticate Negative Acknowledge zurck und beendet die Verbindung. Dies ist natrlich vom Standpunkt der Sicherheit aus betrachtet nicht gerade berauschend, denn jeder, der Zugriff auf die bertragung oder Leitung hat, bekommt eine User-ID samt zugehrigem Passwort praktisch auf dem Prsentierteller geliefert. Dies hat zur Entwicklung eines weiteren Authentifizierungsprotokolls gefhrt, des Challenge Handshake Authentication Protocol. Das Challenge Handshake Authentication Protocol (CHAP) Dieses Protokoll ist fortschrittlicher als PAP, denn hier erfolgt die Authentifizierung in einem dreiphasigen Handshake-Verfahren, ohne dass dabei berhaupt ein Passwort bertragen wird. Die Funktionsweise ist in Kapitel 5 ausfhrlich beschrieben. Das Wesentliche bei CHAP ist, neben seiner hheren Sicherheit, auch die Option, das Protokoll whrend einer bestehenden PPP-Session mehrfach in unregelmigen, nicht vorherbestimmbaren Zeitabstnden auszufhren. Damit kann man verhindern, dass ein Angreifer die Verbindung stiehlt und mit geflschten IP-Adressen die Kommunikation weiterzufhren versucht. Dies kann er nur bis zum nchsten CHAP-Zyklus tun, denn dann muss er als PPP-Peer einen Hashwert berechnen, ohne dass er das CHAP-Secret kennt. Der Angreifer kann dann entweder gar keine oder nur eine falsche CHAPResponse generieren, und die Verbindung wird beendet.
281
Das Compression Control Protocol (CCP) Mit dem CCP handeln PPP-Gegenstellen einen Algorithmus zur Datenkompression aus. Es ist eine ganze Reihe von Algorithmen spezifiziert, jedoch werden von den meisten PPP-Implementierungen nur wenige untersttzt. Die hufigsten sind die Algorithmen von Stack Electronics (Stack LZS) und Microsoft (MPPC), eine Variante von LZS. Im Remote-Access-Bereich sollte aufgrund der Dominanz von Microsoft bei den Clients in jedem Fall dessen Point-to-Point Compression (MPPC) verfgbar sein. Das IP Control Protocol (IPCP) Das wichtigste Protokoll im Bereich der Netzwerksteuerprotokolle ist das IP Control Protocol (IPCP), das die Konfiguration des Internet-Protokolls innerhalb der PPP-Session steuert. Neben der Publizierung oder Zuweisung von IP-Adressen und Netzwerkmasken knnen optional auch DNS- oder WINSAdressen zugewiesen werden. Wie in allen Steuerprotokollen werden hier keine IP-Pakete selbst bertragen, dies erfolgt erst in der Datenphase.
9.1.4
PPP-Verbindungsaufbau
In Abbildung 9.3 ist der zeitliche Ablauf einer PPP-Verbindung von der Initialisierung durch eine Seite bis hin zur Datenphase dargestellt. In der LCPPhase werden die physikalischen Verbindungsparameter und weitere Steuerprotokolle ausgehandelt. Sobald sich die Gegenstellen geeinigt haben, wird das spezifizierte Authentifizierungsprotokoll, im beschriebenen Fall CHAP (Challenge Handshake Authentication Protocol, vgl. Kapitel 5), gestartet. Falls die Authentifizierung erfolgreich ist, werden die weiteren Protokolle gestartet, falls nicht, wird die PPP-Verbindung sofort beendet. In unserem Beispiel konfiguriert das CCP (Compression Control Protocol) anschlieend das Datenkompressionsverfahren, das verwendet werden soll. Falls sich die beiden Gegenstellen nicht einigen knnen, wird hier, im Gegensatz zur fehlgeschlagenen Authentifizierung, die Verbindung nicht terminiert, sondern die Daten werden eben unkomprimiert bertragen. Anschlieend wird das IPCP (IP Control Protocol) ausgefhrt, das die beiden Gegenstellen fr die bertragung von IP-Paketen ber die PPP-Verbindung konfiguriert. Es knnen auch whrend einer Session mehrere Netzwerkprotokolle wie IPX, NetBEUI, VinesIP usw. bertragen werden. PPP ist blicherweise so implementiert, dass nur in ganz wenigen Fllen keine Verbindung zustande kommt. Sobald beide Gegenstellen in der Lage sind, PPP-Pakete zu bertragen, und die Authentifizierung erfolgreich war, gibt es immer einen kleinsten gemeinsamen Nenner, auf den sich beide Gegenstellen einigen knnen. Wenn bestimmte Funktionen oder Parameter
282
nicht mglich sind, ihr Fehlen aber keine fatalen Folgen hat, werden sie ignoriert, oder es werden andere Werte ausgehandelt Hauptsache, man hat eine Verbindung. Es gibt in der Praxis auch nur wenige Flle, in denen ein Abbruch erfolgt, obwohl eine bertragung von PPP-Paketen mglich wre: bei fehlgeschlagener Authentifizierung, falls berhaupt kein Netzwerksteuerprotokoll ausgehandelt werden konnte oder falls eine Seite PPP-Verschlsselung will und die Gegenseite diese nicht untersttzt.
PPP-Endpunkt A LCP Configure Request A LCP Configure Request B LCP Configure Acknowledge B LCP Configure Acknowledge A CHAP Challenge CHAP Response CHAP Accept CCP Configure Request B CCP Configure Acknowledge A IPCP Configure Request B IPCP Configure Acknowledge A PPP-Endpunkt B
IP-Paketbertragung (komprimiert)
Abbildung 9.3: Der PPP-Verbindungsaufbau
Somit stellt sich PPP als wirklich robustes Protokoll auf OSI-Ebene 2 dar, das aus diesem Grund eine weite Verbreitung im Bereich von Whl- und zunehmend auch von Festverbindungen gefunden hat. Insbesondere Einwahlkonzentratoren benutzen fast ausschlielich PPP. Es hat sich daher auch als integraler Bestandteil von Betriebssystemen wie Windows, MacOS, Linux oder OS/2 durchgesetzt, so dass dort keine zustzliche Software fr RemoteAccess-Funktionalitt mehr notwendig ist.
283
9.2
Die Nachteile einer Standard-Remote-Access-Lsung aus Sicht des Endkunden sind allerdings nicht unerheblich. Zum einen sind die bertragungsgebhren hoch, vor allem, wenn viel in der Fernzone oder gar im Ausland gearbeitet wird. Zum anderen ist die Auslastung oft unbefriedigend oder, im anderen Extrem, werden die Konzentratoren berlastet. Im ersteren Fall sind nicht immer alle Ports belegt, also sind die Kosten pro Nutzer hoch, im anderen Fall ist das Gert sehr oft berlastet, und die Benutzer finden besetzte Leitungen vor. Die stndige Kapazittsberwachung und -planung erfordern weitere Ressourcen, ebenso die Wartung des Remote-Access-Equipments. Aus Sicht des Endkunden wre es daher schn, die Technologie nicht selbst zu betreiben. Allerdings wrde er die Verbindungen schon gern selbst terminieren, vor allem auch zur Benutzer-Authentifizierung. Es gibt aber kein einzelnes System, das all dies erledigt. Nun kommt das Layer 2 Tunneling Protocol ins Spiel, in dem der Remote Access Concentrator, wie in Abbildung 9.4 zu sehen ist, in zwei Funktionseinheiten und vor allem in zwei separate Gerte unterteilt wird. Das eine Gert, das von einem Carrier oder ISP betrieben wird, terminiert die Whlverbindungen und den medienabhngigen Teil von PPP, und das zweite Gert auf der Seite des Endkunden terminiert die hheren Schichten der PPP-Sessions. Die Verbindung zwischen den beiden Funktionseinheiten erfolgt ber einen L2TP-Tunnel. Auf diese Weise liegt die reine Einwahl, der Betrieb der Gerte, die Kapazittsplanung usw. auf der Seite der Service Provider, whrend die Terminierung und vor allem auch die Steuerung und Konfiguration der PPPVerbindungen auf der Seite des Endkunden angesiedelt ist.
Rechner mit DF-Client
ISDN PSTN GSM
Internet
L2TP PPP L2TP-Tunnel

Abbildung 9.4: Virtueller Remote Access mit L2TP
284
Intranet
LAC
LNS
9.2.1
Virtueller Remote Access mit L2TP
In der L2TP-Terminologie bezeichnet man die Funktionalitten als LAC (L2TP Access Concentrator) und LNS (L2TP Network Server). In Wirklichkeit hat man dafr oft keine speziellen Gerte, sondern die notwendigen Funktionen werden in bereits vorhandenes Equipment implementiert. So knnen viele Einwahlkonzentratoren sowohl selbst PPP terminieren als auch gleichzeitig als LAC arbeiten und die PPP-Pakete tunneln. Auf der anderen Seite haben viele Router eine zustzliche LNS-Funktionalitt erhalten und knnen L2TP-Tunnel und die darin enthaltenen PPP-Verbindungen terminieren. Letzteres ist aber, und das muss an dieser Stelle erwhnt werden, oft ein extremes Performance-Problem. Denn der Remote Access Concentrator wird dadurch entlastet, dass er als LAC nur noch einen kleinen Teil der PPP-Funktionalitt behlt; der Router bekommt hingegen sehr, sehr viel zustzliche Arbeit, da er nun alle PPP-Sessions anstelle des RAC terminieren muss. Und das ist etwas, wofr ein Router in der Regel von seinem Systemdesign her nicht ausgelegt ist. Lediglich wirklich neue Entwicklungen oder spezielle VPN-Systeme, die dieser Technologie Rechnung tragen, sind fr einen LNS-Einsatz geeignet. In Abbildung 9.5 sind schematisch die Komponenten von L2TP dargestellt. Durch den Tunnel werden sowohl die PPP-Sessions als auch eine Steuerverbindung bertragen, ber die der LAC und der LNS miteinander kommunizieren. Als Tunnelmedium dient heutzutage fast ausschlielich IP; dies ist jedoch nicht zwingend, man kann mit L2TP auch direkt auf niedrigeren Protokollen wie ATM oder Frame Relay aufsetzen oder auch auf Ethernet, denn auf diese Weise, nmlich L2TP ber Ethernet, realisiert man in der Regel die Multilink-Multichassis-Funktionalitt in Einwahlkonzentratoren. In einem L2TP-Tunnel knnen mehrere PPP-Sessions existieren. Sobald die letzte Session abgebaut wurde, baut die Steuerverbindung auch den Tunnel selbst ab.
Abbildung 9.5: Die Komponenten des Layer-2-Tunneling-Protokolls

285
In der Spezifikation des Layer 2 Tunneling Protocol werden bestimmte Begriffe verwendet, deren Bedeutung im L2TP im Folgenden geklrt werden sollte. Call Als Call bezeichnet man eine PPP-Verbindung innerhalb eines L2TP-Tunnels. Der Name kommt daher, dass es sich bei der physikalischen Verbindung meist um eine Whlverbindung (Telefonie, Switched Virtual Circuits usw.) handelt. Innerhalb eines L2TP-Tunnels knnen ein, mehrere oder auch gar kein Call aktiv sein. Control Connection Innerhalb eines L2TP-Tunnels existiert genau eine Steuerverbindung zwischen LNS und LAC. Diese Verbindung steuert den Auf- und Abbau von Calls und Tunneln und berwacht den Zustand eines existierenden Tunnels. Tunnel Im Sinne von L2TP existiert ein Tunnel zwischen LAC und LNS, sobald eine Control Connection zwischen beiden besteht.
9.2.2
PPP-Session-Verteilung in L2TP
Bevor wir uns die Funktionalitt und den Aufbau von L2TP nher ansehen, sollte eine Frage geklrt werden, die sich beim Lesen der vorangegangenen Abstze vermutlich bereits aufgedrngt hat. Woher wei der LAC eigentlich, zu welchem LNS er die PPP-Sessions zu tunneln hat? Die Praxis sieht ja so aus, dass die Provider Hunderte oder Tausende von Einwahlkonzentratoren weltweit betreiben und eine Vielzahl von Kunden betreuen. Diese Kunden legen ihre User aber selbst an und authentifizieren sie auch selbst in ihrem LNS. Der Provider kennt also nicht die Zuordnung von Benutzernamen zu Kundenunternehmen, auerdem kommt hinzu, dass durchaus auch mehrere gleiche Usernamen vorkommen knnen, da die Kunden nichts voneinander wissen und somit identische IDs vergeben knnen. Der LAC muss also folgende Entscheidungen treffen: 1. Ist die PPP-Verbindung lokal zu terminieren? 2. Ist die PPP-Verbindung auf einem ihm bekannten LNS zu terminieren? 3. Existiert bereits ein Tunnel dorthin, oder muss er vorher aufgebaut werden?
286
Es gibt in der Praxis zwei Lsungen fr dieses Problem: zum einen eine Zuordnung der PPP-Session aufgrund eines Zusatzes im Benutzernamen, der whrend der Authentifizierung zum RAC geschickt wird, und zum anderen eine Zuordnung aufgrund der angerufenen Nummer, die beim Rufaufbau bermittelt wird. Beide Mglichkeiten sind in Abbildung 9.6 dargestellt. Call-Verteilung aufgrund des Benutzernamens In diesem Fall wird den User-IDs der Kunden eine so genannte Domain-Kennung angehngt (Suffix) oder vorangestellt (Prfix). Aus dem Benutzernamen mlipp wrde dabei beispielsweise mlipp@nortelnetworks.com werden. Anhand des Suffixes nortelnetworks.com erkennt das Authentifizierungssystem des Service Providers, dass es sich um einen User handelt, der zu einem bestimmten LNS getunnelt werden muss. In seiner Datenbank befindet sich auch der entsprechende Eintrag mit den notwendigen Parametern, um einen Tunnel dorthin aufzubauen. Es ist offensichtlich, dass der LAC in diesem Fall das LCPProtokoll und sogar einen Teil des Authentifizierungsprotokolls abwickeln muss. Denn erst dann, wenn die sich einwhlende PPP-Gegenstelle ihre Identitt in Form eines Benutzernamens bekannt gibt, kann der LAC anhand des Suffixes oder Prfixes entsprechend agieren. Da aber die Authentifizierungsphase nach Beendigung des LCP erfolgt, muss das Link Control Protocol komplett vom LAC abgewickelt werden. Der LNS bekommt von der Verbindungsaushandlung erst einmal gar nichts mit. Falls im LCP als Authentifizierungsprotokoll CHAP ausgehandelt wird, muss der LAC sogar ein CHAP-Challenge erzeugen. Als erstes Indiz fr einen neuen Call bekommt der LNS ein Authentifizierungspaket vom LAC zugeschickt, in dem User-ID und Kennwort (PAP-Authentifizierung) oder CHAP-Challenge, CHAP-Response und User-ID (CHAP-Authentifizierung) enthalten sind. Falls der LNS selbst mit der sich einwhlenden PPP-Gegenstelle ber LCP die Verbindung aushandeln will, kann er durch den L2TP-Tunnel selbst noch einmal LCP starten. Dabei knnen alle bereits zwischen PPP-Client und LAC ausgehandelten Optionen, inklusive des Authentifizierungsprotokolls, neu ausgehandelt werden, und es wird eine neue Authentifizierung durchlaufen. Dies ist ein mgliches Verhalten des LNS. Ein anderes, schnelleres, besteht darin, die vom LAC begonnene Authentifizierung zu komplettieren, sich die bereits ausgehandelten LCP-Optionen mitteilen zu lassen und zu prfen, ob sie akzeptabel sind. Nur falls dies nicht der Fall ist, kann der LNS noch einmal das LCP starten.
287
Client A
User-ID: mlipp@nortel.com 109.244.1.2
Netzwerk B
LAC ISDN PSTN TMS

Client B
Ruft 071175234 an 144.10.23.1
LNS Internet
Netzwerk A
LNS
Tunnel-Management-Server (TMS) Datenbank
Call placement (DNIS=071175234)
DNIS 0711 75234 0605 14625 ..... .....
Endpoint
Secret
Type L2TP L2TP
144.10.23.1 F5sg2H 192.20.3.4 ga67h
LCP/Auth (mlipp@nortel.com)
Domain nortel.com pearson.de .... ....
Endpoint 109.244.1.2 190.19.3.9
Secret g28Gh4 9sgtaz
Type L2TP L2TP
L2TP-Tunnel
PPP-Session
Abbildung 9.6: Call- und Tunnelverteilung aufgrund der angerufenen Nummer (DNIS, Dialed Number Information String) oder eines Zusatzes im Benutzernamen
Call-Verteilung aufgrund der gewhlten Nummer Dieses Verfahren macht sich den Umstand zunutze, dass ein physikalischer Telefonanschluss ber mehrere Nummern aus einem so genannten Rufnummernblock erreichbar sein kann. Jeder Kunde bekommt also eine eindeutige Nummer, mit der er sich beim Provider einwhlt. Die angerufene Nummer wird bei der Einwahl dem Authentifizierungssystem bergeben, das zu dieser Nummer (DNIS, Dialed Number Information String) einen entsprechenden Eintrag in seiner Datenbank hat. In diesem Fall nimmt der LAC berhaupt nicht an der Authentifizierung teil. Diese und der grte Teil der LCP-Aushandlungen finden direkt zwischen dem LNS und der PPP-Gegenstelle statt.
288
Heutige Einwahlkonzentratoren und Authentifizierungssysteme, zumeist RADIUS-Server, kennen beide Verfahren und knnen diese gleichzeitig sogar gleichzeitig fr einen Kunden verwenden.
9.2.3
Die Rolle des LAC (L2TP Access Concentrator)
Der L2TP Access Concentrator (LAC) ist fr die Verarbeitung der medienabhngigen PPP-Schichten verantwortlich und entscheidet, ob eine eingehende Verbindung als normale PPP-Verbindung lokal terminiert wird oder ob ein Tunnel zu einem LNS aufgebaut werden muss. Je nachdem auf welche Art diese Entscheidung getroffen wird aufgrund des DNIS oder des Benutzernamens , fhrt der LAC zustzlich noch einen Teil der Authentifizierung durch. Wie bereits erwhnt wurde, ist die LAC-Funktionalitt meist auf DialIn-Systemen in den POPs von Service Providern und Carriern implementiert. Solche Systeme sind in der Lage, sowohl selbst PPP zu terminieren als auch PPP-Verbindungen zu tunneln. Die zustzliche L2TP-LAC-Funktionalitt bringt in den meisten Implementierungen keine Performanceprobleme mit sich, da meist nur ein Tunnel zu den Kundennetzen aufgebaut werden muss, durch den mehrere Calls geleitet werden knnen. Auerdem findet der grte Teil der PPP-Verarbeitung dabei nicht mehr auf dem LAC, sondern auf dem LNS statt. Dies spart ebenfalls Speicher- und Rechenzeitressourcen auf dem Einwahlsystem.
9.2.4
Die Rolle des LNS (L2TP Network Server)
Der L2TP Network Server (LNS) ist das Gert, auf dem die PPP-Verbindungen der Remote-Access-Clients terminiert werden. Hier arbeiten alle Dienste zum Ver- und Entpacken der Netzwerkprotokolle, der Datenkomprimierung, der Authentifizierung und der Kontrolle der Verbindungsqualitt. Lediglich die medienabhngigen Dienste werden vom LAC abgewickelt. Zustzlich zur LNS-Funktionalitt muss eine Schnittstelle zu Authentifizierungs- und Accountingsystemen existieren, meist zu RADIUS-Servern, die sich als dominierender Standard hierfr durchgesetzt haben.
9.2.5
Betrachtungen zur Performance von L2TP
Je nach Anwendungsfall sind auf einem LNS mehrere hundert oder tausend PPP-Sessions gleichzeitig zu terminieren. Dies stellt natrlich gewisse Anforderungen an die Leistungsfhigkeit eines solchen Systems. Viele Hersteller haben die L2TP-LNS-Funktionalitt als zustzliches Feature auf ihren Routern implementiert. Man kann dies zwar nicht verallgemeinern, aber hierbei kann es zu deutlichen Performanceeinbuen auf solchen Systemen kommen. Die meisten Hersteller weisen jedoch fairerweise auf solche
289
Einschrnkungen hin. Diese Leistungsengpsse werden nicht dadurch verursacht, dass die Gerte nichts taugen, sondern entstehen aufgrund des Routerdesigns. Die meisten Router wurden schon vor etlichen Jahren entwickelt mit dem ausschlielichen Ziel zu routen und die notwendigen LAN- und WAN-Interface-Protokolle zu terminieren. Die Systeme wurden fr diesen Zweck optimiert, und zwar sowohl im Hinblick auf die Hard- als auch auf die Software. Das Resultat sind sehr leistungsfhige Routerplattformen. Werden diese allerdings fr andere Funktionen verwendet, fr die sie nicht ausgelegt sind, so werden nicht nur diese Funktionen mit mangelhafter Performance ausgefhrt, sondern das ganze System bekommt letztendlich Leistungsprobleme. Dies betrifft sowohl im Falle von L2TP das Terminieren von Hunderten oder Tausenden von PPP-Sessions als auch, wie im vorhergehenden Kapitel erlutert, die Verschlsselungsfunktionen in IPSec. Nehmen wir als anschauliches Beispiel einmal einen Router der Mittelklasse, der zwei WAN- und zwei LAN-Interfaces aufnehmen kann und die im Unternehmensbereich blichen Routingprotokolle beherrscht. Beim Design eines solchen Systems ist unter anderem die Wirtschaftlichkeit eine Vorgabe. Es darf keine berdimensionierung dahin gehend geben, dass zu teure Prozessoren und zu viel Speicher eingebaut werden. An dem Gert muss ja schlielich auch etwas verdient werden, und es hat konkurrenzfhig zu sein. Hier setzt man als Szenario typischerweise an, dass die beiden WAN-Schnittstellen mit maximal 2 Mbit/s betrieben werden und darauf Protokolle wie PPP, Frame Relay, X.21 usw. laufen. Die LAN-Interfaces sind meist EthernetSchnittstellen mit 10 bzw. 100 Mbit/s. Wenn man bei der Kalkulation der bentigten Leistung im WAN-Bereich den schlimmsten Fall annimmt, dann mssen die beiden WAN-Schnittstellen ber ein entsprechendes Leitungsprotokoll insgesamt 62 mal 64 Kbit/s mit PPP terminieren. Wenn nun zustzlich in ein solches System LNS-Funktionalitt implementiert wird, dann kommen Protokolle wie L2TP und RADIUS hinzu. Auf den WANSchnittstellen selbst werden in typischen Szenarien zwar nur noch pro Interface einmal die entsprechenden Link-Protokolle terminiert, es kommen pro eingewhltem Benutzer aber jeweils eine PPP-Session und pro Datenpaket die entsprechenden Kapselungsdienste von L2TP hinzu. Wenn nun die Zahl der Benutzer, was nicht unblich ist, in die Hunderte oder gar Tausende geht, dann werden auch ebenso viele PPP-Sessions auf diesem Router terminiert. Und dafr sind die meisten Systeme einfach nicht konstruiert. Abhilfe schaffen hier spezielle VPN-Systeme, deren Hard- und Softwaredesign speziell auf eine solche Funktionalitt ausgelegt ist. Hier wurden bereits beim Design die Rahmenbedingungen beim Einsatz als virtueller Remote Access Concentrator oder IP Security Gateway bercksichtigt.
290
Weitere Kriterien bei der berlegung, L2TP einzusetzen, sind auch die Performance und die Qualitt der bertragungsstrecke zwischen LAC und LNS. Herkmmlicher Remote Access wird auf Basis von leitungsvermittelnden Netzen wie ISDN oder analogen Telefonnetzen betrieben. Hierbei erfolgt die bertragung der Datenpakete mit der technisch mglichen Geschwindigkeit, z.B. 64 Kbit/s bei ISDN, und minimaler Verzgerung. Auerdem kommen die Pakete in der Reihenfolge an, in der sie abgeschickt wurden oder gar nicht. Vertauschungen bei der Reihenfolge gibt es in der Regel nicht. Das PPP-Protokoll luft in diesem Fall auf einer realen Punkt-zu-Punkt-Verbindung, wofr es ursprnglich auch entwickelt wurde. L2TP macht damit Schluss. Denn hier wird die reale Punkt-zu-Punkt-Verbindung durch den L2TP-Tunnel ersetzt, der jedoch auch ber Nicht-Punktzu-Punkt-Verbindungen laufen kann. Oft werden L2TP-Pakete in UDP/IP eingekapselt und zwischen LAC und LNS bertragen. In der Praxis ist das verwendete IP-Netzwerk das Internet oder der Backbone eines Carriers oder Service Providers. Das Resultat: Weder die Geschwindigkeit noch die Reihenfolge, in der die Pakete ankommen, sind vorherbestimmbar und knnen je nach Last auf dem Transportnetz groen Schwankungen unterliegen. Also mssen auf der einen Seite LAC und LNS zustzliche Funktionen zur Verfgung stellen, um Probleme zu entschrfen, die insbesondere bei einer Vertauschung der Paketreihenfolge entstehen. Als Beispiel sei an dieser Stelle die Van-Jacobson-(VJ)-TCP-Header-Komprimierung genannt. Dieses Verfahren macht sich die Tatsache zunutze, dass die Informationen in aufeinander folgenden TCP/IP-Headern nur in ganz wenigen Bits voneinander abweichen, und bertrgt, nachdem der erste vollstndige Header gesendet wurde, nur noch die Differenz zum jeweils vorhergehenden. Auf diese Weise spart man Bandbreite. Das funktioniert aber logischerweise nur, wenn die Reihenfolge der Pakete nicht verndert wird, was bei echten Punkt-zu-Punkt-Verbindungen, nicht aber bei UDP/IP gegeben ist. Hier muss entweder das darunter liegende Protokoll, also L2TP, zustzliche Manahmen einfhren, um die Paketreihenfolge einzuhalten, oder es kann der Fall eintreten, dass jedes Mal, wenn ein Paket nicht in der richtigen Reihenfolge ankommt, der VJ-Algorithmus annimmt, das Paket wre verloren, und so lange alle weiteren eingehenden Pakete verwirft, bis ein Paket mit vollstndigem TCP/IP-Header eintrifft. Das wre natrlich ein Performanceverlust anstelle eines Gewinns. Andere Beispiele sind Kompressions- oder Verschlsselungsprotokolle, die auf so genannten Histories basieren und damit ebenfalls eine unvernderte Reihenfolge der eingehenden Pakete bentigen. L2TP muss also bestimmte, kritische Eigenschaften einer realen Punktzu-Punkt-Verbindung emulieren, insbesondere hinsichtlich der Paketreihenfolge und der Signalisierung an das PPP-Protokoll, ob Pakete verloren wurden. Dies bedingt einen zustzlichen Paket-Overhead der L2TP-Datenpakete
291
durch Sequenzzhler und erfordert eine zustzliche Verarbeitungsleistung, ebenso wie einen greren Speicherbedarf zur Zwischenspeicherung von Paketen, die auerhalb der korrekten Reihenfolge angekommen sind.
9.2.6
L2TP-Tunneling-Modelle
Das Layer 2 Tunneling Protocol kann in zwei verschiedenen Modellen (vgl. Kapitel 6) betrieben werden, dem Provider-Enterprise-Modell (Compulsory Tunneling) und dem Ende-zu-Ende-Modell (Voluntary Tunneling).
Compulsory-Tunneling-Modell Client A
Netzwerk A
LAC
Virtual LAC
LNS Internet
Netzwerk B
ISDN PSTN TMS
Client B Voluntary-Tunneling-Modell
L2TP-Tunnel
LNS
PPP-Session
Abbildung 9.7: Die beiden Tunneling-Modelle von L2TP
In Abbildung 9.7 sind beide Modelle dargestellt. Die beiden Modelle unterscheiden sich durch den Punkt, an dem der L2TP-Tunnel initiiert wird. Der Remote-Access-Client A whlt sich in den Einwahlkonzentrator eines Service Providers ein und wird an dieser Stelle zum LNS seines Zielnetzwerks getunnelt. Der Client selbst hat keinen Einfluss auf das Tunneln, dies wird allein vom LAC gesteuert. Aus diesem Verhalten ist auch die englische Bezeichnung Compulsory Tunneling, zwangsmiges Tunneln, abgeleitet. Mit diesem Modell kann der Service Provider einem Kunden garantieren, dass dessen Clients jedes Mal, wenn sie sich anmelden, unbedingt zu einem entsprechend eingerichteten LNS getunnelt werden und keinen direkten Zugriff auf das Netzwerk des Providers oder das Internet haben. Das Entscheidungskriterium fr den LAC ist hier die angerufene Nummer (DNIS) oder ein Zusatz im Benutzernamen. Voluntary Tunneling, freiwilliges Tunneln, ist das andere Modell, das mit L2TP realisiert werden kann. In dieser Variante ist der Remote Access Concentrator des Service Providers in keiner Weise in das Tunneln involviert. Statt dessen
292
ist die LAC-Funktionalitt auf dem Client, Client B in Abbildung 9.7, implementiert. Der Tunnel beginnt also bereits im Clientrechner (virtueller LAC) und wird im entsprechenden LNS terminiert. Der Einwahlkonzentrator selbst bertrgt dabei nur IP-Pakte zwischen Client und LNS. In diesem Fall kann der Client selbst entscheiden, ob und wie getunnelt wird. Dieses Modell wird in der Praxis jedoch sehr selten eingesetzt, da die Kunden in der Regel mchten, dass die Clients zwangsweise zum eigenen Netzwerk getunnelt werden.
9.2.7
L2TP-Paketformate
In L2TP existieren zwei funktionell grundstzlich verschiedene, aber hnlich konstruierte Arten von Paketen. Dies sind zum einen Datenpakete, die PPPFrames innerhalb eines Calls zwischen LAC und LNS transportieren, und zum anderen Steuerungspakete, die innerhalb einer Steuerverbindung zwischen LAC und LNS verschickt werden.
0 1 5 3 Length (optional) Call ID Nr (optional) Offset Pad (optional) 1
0 L 0 0 F 0 S P 0 0 0 0 0 Vers. Tunnel ID Ns (optional) Offset Size (optional)
Data (PPP Frame)
Abbildung 9.8: Das Format eines L2TP-Datenpakets
In Abbildung 9.8 ist die Struktur eines L2TP-Datenpakets zu sehen. Die Hauptfunktion ist die Kapselung eines PPP-Rahmens in ein L2TP-Paket und die Zuordnung des Pakets zu einem Tunnel und einem Call innerhalb dieses Tunnels. Weiterhin knnen optional Sequenzzhler zur Steuerung der Paketreihenfolge und Fllzeichen (Padding) enthalten sein. Die Felder in einem Datenpaket haben folgende Bedeutung: T-Bit Das T-Bit ist das erste Bit in einem L2TP-Paket und zeigt an, ob es sich um ein Datenpaket (0, wie in Abbildung 9.8) oder um ein Steuerungspaket (1, wie in Abbildung 9.9) handelt.
293
L-Bit Dieses Bit zeigt an, ob in dem Paket ein Lngenfeld (1) enthalten ist oder nicht (0). In Steuerungspaketen muss ein Lngenfeld enthalten sein, in Datenpaketen kann in vielen Fllen darauf verzichtet werden. F-Bit Wenn dieses Bit gesetzt (1) ist, dann sind im Paket die Sequenzzhler Ns und Nr enthalten. In Steuerungspaketen sind diese obligatorisch, in Datenpaketen sind sie optional.
0 15 Length Call ID Nr
Overall Length Attribute
......... Value ......... ......... Value
MH 0 0 0 0
Overall Length Attribute
......... Value
31
1 1 0 0 1 0 0 0 0 0 0 0 0 Vers. Tunnel ID Ns
MH 0 0 0 0
Vendor ID Value .......
Vendor ID Value .......
Abbildung 9.9: Das Format eines L2TP-Steuerungspakets mit zwei AVPs (Attribute Value Pairs)
S-Bit Falls das Offset-Size-Feld vorhanden ist, muss das S-Bit gesetzt werden. In L2TP-Steuerungspaketen muss dieses Bit immer 0 sein, da dieses Feld dort nicht existiert. Version Dies ist die Versionsnummer von L2TP; der augenblicklich einzig gltige Wert ist 2. Length Dieser 16-Bit-Wert gibt die vollstndige Lnge des L2TP-Pakets in Byte an. Ein Paket kann somit maximal 65.535 Byte gro sein.
294
Tunnel ID Dies ist der eindeutige Bezeichner eines bestimmten L2TP-Tunnels. Er wird gem der L2TP-Spezifikation auf Zufallsbasis erzeugt. Mit Hilfe der Tunnel ID kann der Empfnger des Pakets dieses einem bestimmten Tunnel zuordnen. Call ID Die Call ID ist ein innerhalb eines Tunnels eindeutiger Bezeichner eines Calls, also einer PPP-Session. Auch er wird auf Zufallsbasis erzeugt. Durch die Gre des Bezeichners von 16 Bit ist die maximale Anzahl von Calls, die in einem Tunnel existieren knnen, auf 65.535 beschrnkt. Ns Dieser Wert (Ns, Next Send) stellt die Sequenznummer eines Pakets dar. In Steuerungspaketen muss dieser Wert enthalten sein, in Datenpaketen ist er optional und dient dort zur Steuerung der korrekten Paketreihenfolge. Nr Next Received (Nr) ist die Sequenznummer des Steuerungspakets, das der Sender des vorliegenden Pakets als Nchstes empfangen mchte. In Datenpaketen hat dieser Wert keinen Sinn und wird daher auf 0 gesetzt. Offset-Size Diesen Wert gibt es nur in Datenpakten, falls dort das S-Bit gesetzt wurde. Er gibt an, wie viele Byte zwischen dem L2TP-Header und dem PPP-Frame liegen. Offset-Pad In den Zwischenraum zwischen L2TP-Header und PPP-Frame wird, falls der Wert Offset-Size grer 0 ist, die Anzahl von Fllzeichen geschrieben, die dem Wert von Offset-Size entspricht. Die Fllzeichen sind in der Regel Bytes mit dem Wert 0x00.
9.2.8
L2TP Attribute Value Pairs (AVP)
In Steuerungspaketen sind so genannte AVPs (Attribute Value Pairs) enthalten, die diejenigen Befehle und Optionen enthalten, die zwischen LAC und LNS ausgetauscht werden. Diese Datenstrukturen bestehen aus einem festen Header, der auch den Bezeichner des jeweiligen Attributs enthlt, und einem Attributwert variabler Lnge. In Abbildung 9.9 folgen zwei verschiedene AVPs dem L2TP-Steuerungspaket-Header.
295
Im AVP-Header finden wir verschiedene Flags und Felder mit folgender Bedeutung: M-Bit Dieses Flag (M, Mandatory) zeigt an, ob der AVP zwingend ist, und steuert damit das Verhalten des Empfngers, falls dieser ein AVP mit gesetztem M-Bit empfngt, aber mit dem Inhalt des AVP nichts anfangen kann. In diesem Fall, der dann vorliegt, wenn entweder die Vendor-ID, der Attributbezeichner oder beide unbekannt sind, muss der Empfnger den Tunnel beenden. H-Bit Das H-Bit (Hide-Bit) wird dann gesetzt, wenn der Wert des AVP versteckt sein soll. Dies wird durch die Verschlsselung des Value-Feldes erreicht. Die ersten sechs Bytes (Flags, Overall Length, Vendor-ID und Attribute) eines AVP sind immer unverschlsselt.
RND
Initialisierungsvektor
Shared Secret
MD 5
Attribute
Klartextblock 1
Chiffretextblock 1
Shared Secret
MD 5
Klartextblock 2
Chiffretextblock 2
Abbildung 9.10: Der AVP-Verschlsselungsalgorithmus
Eine praktische Anwendung fr versteckte, beziehungsweise verschlsselte AVPs ist die Proxy-Authentifizierung. Dabei schickt der LAC die User-ID und
296
das Passwort des PAP-Protokolls zum LNS. Da diese Informationen im Klartext vorliegen, sollten sie beim Transport ber ein ffentliches Netz wie das Internet verschlsselt werden. Die in L2TP spezifizierte Verschlsselung ist allerdings vom Sicherheitsstandpunkt aus gesehen nicht gerade umwerfend. Der Algorithmus zum Ver- und Entschlsseln ist eine schlichte Exklusiv-Oder-Verknpfung des Klartextes mit einem 128 Bit groen Schlssel. Dieser Schlssel wird aus einer Zufallszahl, die mit einem CBC-Initialisierungsvektor vergleichbar ist, dem Attribut und einem Shared Secret mit Hilfe der MD5-Funktion berechnet. Dieses Shared Secret wird auch, wie in Kapitel 9.2.9 beschrieben wird, zur Authentifizierung von LNS und LAC beim Aufbau eines L2TP-Tunnels benutzt. Die MD5-Funktion ist als Basis des CHAP-Verfahrens ebenfalls bereits im System vorhanden. Die Verschlsselung arbeitet, wie in Abbildung 9.10 zu sehen ist, in einem Output-Feedback-Modus mit einem expliziten Initialisierungsvektor. Aus dem Shared Secret, dem Attributwert und dem Initialisierungsvektor wird ber MD5 ein 128 Bit groer Wert erzeugt, der mit den ersten 16 Byte des originalen AVP-Subformats Exklusiv-Oder-verknpft wird. Damit sind die ersten 16 Bytes verschlsselt. Aus diesem Wert und dem Shared Secret wird ber MD5 wieder ein 128-Bit-Wert erzeugt, mit dem die nchsten 16 Bytes verschlsselt werden. Dies wird so lange weitergefhrt, bis der originale Wert vollstndig verschlsselt ist. Aus Sicherheitsgrnden wird die Lnge des originalen Wertes im Value-Feld verschleiert, indem man ein so genanntes Hidden-AVP-Subformat erzeugt, das aus einem Lngenfeld, dem Originalwert und Fllzeichen besteht. Dieses Format wird mit dem beschriebenen Verfahren verschlsselt und als Wert in das Value-Feld des AVP eingetragen. An dieser Stelle sei auch bereits darauf hingewiesen, dass die Verschlsselung nur auf Steuerungspakete (siehe Abbildung 9.9) angewendet werden kann, nicht jedoch auf L2TP-Datenpakete. Overall Length Dieses Feld gibt die Gesamtlnge des AVP in Byte an. Vendor ID Fr AVPs, die von der IETF spezifiziert worden sind, ist dieser Wert 0. Herstellerspezifische AVPs enthalten eine Vendor ID, die der von der IANA (Internet Assigned Numbers Authority) zugewiesenen Nummer gem dem RFC1700 entspricht. Somit ist die Kombination von Attribut und Vendor ID weltweit eindeutig, denn selbst wenn unterschiedliche Hersteller die gleichen Attributbezeichner verwenden, so unterscheiden sie sich doch durch ihre Vendor ID.
297
Attribute Dieses Feld enthlt den Bezeichner des Attributs als 16-Bit-Wert. Value In diesem Feld steht der Wert des Attributs. Er kann, innerhalb der maximalen Gre des AVP, beliebig lang sein, und sein Wert wird vom Empfnger anhand des Attribute- und Vendor-ID-Feldes interpretiert.
9.2.9
Auf- und Abbau von Tunneln und Calls in L2TP
In Abbildung 9.11 ist der Auf- und Abbau eines Calls und eines Tunnels in zeitlicher Abfolge skizziert. Es wird in diesem Beispiel davon ausgegangen, dass zum Zeitpunkt des Calls noch kein Tunnel zwischen dem LAC und dem LNS existiert. Die Erkennung und Zuweisung einer Tunnelverbindung durch den LAC soll aufgrund der DNIS-Information bei Rufaufbau erfolgen.
Client ISDN PSTN
Callplacement TMSQuery TMSReply
LAC Internet
LNS
RADIUS
TMS
DNIS-Eintrag vorhanden
Start-control-connection-request
Start-control-connection-reply Start-control-connection-connected
LCP
Negotiation Incoming-call-request(Auth.)
Authent. Request
Authent. Reply
Incoming-call-reply Callcompletion Incoming-call-connected ForwardLCPOptions NCP(IPCP ,CCP ,...)Negotiations
L2TPDatamessages(PPPFrames)
Calldisconnect
Stop-control-connection-notify Call-disconnect-notify
Abbildung 9.11: Der Auf- und Abbau eines Tunnels und eines Calls in L2TP
298
Der Client, ein Remote-Access-System mit PPP, baut eine Whlverbindung zum Einwahlkonzentrator auf. Der Remote Access Concentrator schickt daraufhin ein Authentication-Request-Paket zum Tunnel-Management-System (TMS), das meist ein RADIUS-Server ist. In diesem Paket ist unter anderem auch die DNIS-Information enthalten. Das TMS findet in unserem Fall zu dieser Rufnummer einen Eintrag, in dem die folgenden Informationen enthalten sein mssen: die Art des aufzubauenden Tunnels (L2TP, L2F usw.) und die Zieladresse des LNS, zu dem der Tunnel aufgebaut werden soll. Meist ist noch ein Shared Secret hinterlegt, mit dem der Tunnelaufbau authentifiziert werden kann und Hidden-AVPs verschlsselt werden knnen. Mit diesen Parametern versucht nun der LAC, einen Tunnel zum LNS aufzubauen, indem er einen Start-control-connection-request an den LNS schickt. Der LNS antwortet mit einem Start-control-connection-reply, falls er dem Wunsch des LAC, einen Tunnel zu erzeugen, folgt. Sobald der LAC diese Antwort erhlt, komplettiert er seinen Tunnelaufbau, und beide Seiten, LAC und LNS, sind ber eine Control Connection miteinander verbunden. Im Sinne von L2TP ist damit ein Tunnel aufgebaut. Innerhalb dieses dreiphasigen Handshake-Verfahrens kann auch die Authentifizierung der beiden Tunnelendpunkte erfolgen. Dazu wird ein dem CHAPVerfahren analoger Mechanismus auf Basis von MD5 mit Challenge-, Response- und Accept/Reject-Paketen unter Verwendung eines Shared Secret auf LAC und LNS eingesetzt. Da der Tunnel aufgrund der DNIS-Informationen aufgebaut wurde, brauchte der LAC bisher nur minimale LCP-Operationen auszufhren. Die restlichen LCP-Aushandlungen knnen jetzt durch den Tunnel zwischen dem Client und dem LNS direkt erfolgen, ohne dass der LAC noch involviert ist. Nachdem die bertragungsparameter und Authentifizierungsprotokolle ausgehandelt wurden, kann die Authentifizierung des Benutzers (Clients) erfolgen. Da der LNS die LCP-Optionen, die der LAC bereits mit dem Client ausgehandelt hat, nicht kennt, schickt ihm dieser seine Optionen in einem Informationspaket (Forward LCP-Options) zu. Somit kennt der LNS alle LCP-Optionen, die von ihm selbst und die vom LAC ausgehandelt wurden, und er hat den Benutzer authentifiziert. Nun knnen die Netzwerksteuerungsprotokolle gestartet werden, und nach deren Abschluss knnen L2TP-Datenpakete und damit auch Netzwerkpakete bertragen werden. Wird die Verbindung vom Client unterbrochen, also der Call terminiert, kann auch der Tunnel selbst abgebaut werden, wenn sonst keine weiteren Calls in diesem Tunnel mehr aktiv sind. Der Abbau wird ebenfalls ber entsprechende Steuerungspakete geregelt.
299
9.2.10
L2TP-Benutzer-Authentifizierung
Die Benutzer-Authentifizierung lsst sich in drei verschiedene Stufen untergliedern, die sich dadurch unterscheiden, inwieweit der LAC in die Authentifizierung involviert ist. Im ersten Fall, in dem der LAC aufgrund der DNISInformationen beim Aufbau der Whlverbindung bereits erkennen kann, dass ein L2TP-Tunnel zu einem LNS aufgebaut werden soll, erfolgt die Authentifizierung vollstndig zwischen dem LNS und der PPP-Gegenstelle. Der LNS handelt alle LCP-Optionen aus und ebenso das zu verwendende Authentifizierungsprotokoll. Protokolle wie PAP, CHAP oder MS-CHAP (Microsoft CHAP, eine Microsoft-spezifische Variante von CHAP) werden zwischen LNS und der einwhlenden Gegenstelle direkt abgewickelt. Diese Variante, die allerdings nur mit einer auf DNIS basierenden Tunnelverteilung funktioniert, ist problemlos mit allen PPP-Implementierungen auf der Clientseite mglich. Fr den Client sieht es so aus, als ob er nur mit einer einzigen Instanz und nicht mit dem LAC und dem LNS kommuniziert. Die anderen beiden Verfahren zur Benutzer-Authentifizierung basieren darauf, dass in der User-ID (Benutzername, CHAP-Name usw.) eine Kennung enthalten ist, aufgrund derer der LAC entscheiden muss, ob und wohin ein Tunnel aufzubauen ist. Um aber in den Besitz einer User-ID zu gelangen, muss der LAC das vollstndige LCP abwickeln und die Authentifizierung so lange durchfhren, bis er die ntigen Informationen erhlt. Diese Funktionalitt wird auch als Proxy Authentication bezeichnet, da der LAC anstelle des LNS die notwendigen ersten Schritte zur Authentifizierung des Benutzers durchfhrt.
Client ISDN PSTN LAC Internet LNS
RADIUS
Call placement TMS Query TMS Reply
TMS DNIS-Eintrag vorhanden
Tunnelaufbau LCP Negotiation Authentifizierung (PAP, CHAP, MS-CHAP) Authent.
Abbildung 9.12: Die L2TP-Benutzer-Authentifizierung bei DNIS-basierender Erzeugung der Tunnel
300
Im Fall unserer Beispiele in Abbildung 9.13 und Abbildung 9.14 mit PAP als Authentifizierungsprotokoll erhlt der LAC ein PAP-Authentication-RequestPaket, in dem der Benutzername und das Passwort enthalten sind. Aufgrund der User-ID kann der LAC erkennen, dass ein L2TP-Tunnel zum LAC aufgebaut werden muss, und er baut diesen auf. Anschlieend schickt der LAC das Authentication-Request-Paket zum LNS. Dieser kann jetzt entweder die Authentifizierung wie in Abbildung 9.13 einfach fortfhren, oder er kann noch einmal LCP starten, neue Optionen und sogar ein anderes Authentifizierungsverfahren mit der PPP-Gegenstelle aushandeln (LCP Renegotiation) und dieses dann auch ausfhren. Im ersten Fall wird der Benutzer authentifiziert, und der LNS akzeptiert die bereits vom LAC ausgehandelten LCP-Optionen und das Authentifizierungsprotokoll. Im zweiten Fall startet der LNS noch einmal LCP-Aushandlungen mit dem Client, in deren Folge sich beide auch auf ein anderes Authentifizierungsprotokoll einigen knnen, das anschlieend ausgefhrt werden muss.
Client ISDN PSTN
TMS
Call placement TMS Query
LAC Internet
LNS
RADIUS
LCP
Negotiation ..., PAP,
PAP-Auth-Req
TMS Reply
Kein DNISEintrag vorhanden
TMS Query TMS Reply
Domain-Eintrag vorhanden
Tunnelaufbau
PAP-Auth-Req-Forward
Authent.
PAP-Authentication-Accept
Abbildung 9.13: Partielle Benutzer-Authentifizierung auf dem LAC (Proxy Authentifizierung)
Allerdings kann dieses Verhalten (siehe Abbildung 9.14) neue LCP-Aushandlung und eine Wiederholung der Authentifizierung bei gewissen PPPImplementierungen in lteren PC-Betriebssystemen auch Probleme bereiten. Die Verbindung wird schlicht abgebrochen, da dieses Verhalten, insbesondere eine bereits ausgehandelte und begonnene Authentifizierung neu auszuhandeln und zu starten, in PPP zwar erlaubt ist, aber gewhnlich niemals vor301
kommt. In diesem Fall muss der LNS die Authentifizierung fortfhren, was aus Geschwindigkeitsgrnden auch meist das bliche Verhalten ist. Die meisten LNS-Implementierungen starten nur dann eine LCP-Neuaushandlung, wenn die vom LAC bereits ausgehandelten Optionen und Authentifizierungsverfahren fr sie nicht akzeptabel sind. Dies ist aber nur sehr selten der Fall, da die meisten LNS auf die meistens bereits in den Systemen vorhandene PPP-Funktionalitt aufbauen.
Client ISDN PSTN TMS
Call placement TMS Query LCP Negotiation ..., PAP, PAP-Auth-Req TMS Query TMS Reply TMS Reply
LAC Internet
LNS
RADIUS
Tunnelaufbau PAP-Auth-Req - Forward LCP Renegotiation (...., CHAP, ....) CHAP-Challenge CHAP-Response Authent. CHAP-Authentication-Accept
Abbildung 9.14: Eine L2TP-Benutzer-Authentifizierung, in der der LNS die LCP-Optionen und das Authentifizierungsprotokoll ndert (LCP Renegotiation)
Noch weiter in die Authentifizierung involviert wird der LAC im Falle von CHAP. In Abbildung 9.15 sehen wir, dass der LAC in diesem Fall den dreiphasigen CHAP-Zyklus startet. Er erzeugt dazu eine Zufallszahl und schickt diese in einem CHAP-Challenge-Paket zum Client. Dieser erzeugt aus seinem Passwort und der Zufallszahl mit der MD5-Funktion einen Hashwert und schickt diesen, zusammen mit seiner User-ID, in einem CHAP-Response Paket zum LAC. Der LAC schaut sich die User-ID an und prft, ob dort eine Domainkennung enthalten ist. Wenn ja, wird mit den Informationen, die der Tunnel-Management-Server (TMS) zu dieser Domain hat, ein Tunnel zum entsprechenden LNS aufgebaut.
302
Die Sicherheit von L2TP
Client ISDN PSTN
LAC Internet TMS

Call placement TMS Query LCP Negotiation ..., CHAP, TMS Reply
LNS
RADIUS
CHAP-Challenge CHAP-Response TMS Query TMS Reply
Tunnelaufbau
CHAP-Chall. + CHAP-Resp. Fwd. CHAP-Authentication-Accept
Authent.
Abbildung 9.15: L2TP-Proxy-Authentifizierung am Beispiel von CHAP
Anschlieend bermittelt er dem LNS die von ihm erzeugte CHAP-Challenge zusammen mit der CHAP-Response des Clients. Der LNS berprft nun die Identitt des Benutzers und erzeugt, abhngig vom Ergebnis der Authentifizierung, eine CHAP-Accept- oder CHAP-Reject-Message. In diesem Beispiel (Proxy-Authentifizierung) sehen die LCP-Aushandlung und die Authentifizierung fr den Client so aus, als ob er mit einer einzigen PPP-Gegenstelle kommuniziere. Es erfolgen keine, aus Sicht von PPP, ungewhnlichen Aktivitten wie LCP-Neuaushandlung oder Neustart des Authentifizierungsprotokolls, ohne dass das vorhergehende Protokoll ordnungsgem terminiert wurde.
9.3
Die Sicherheit von L2TP
Genau genommen msste die berschrift zu diesem Unterkapitel eigentlich lauten: Die Unsicherheit von L2TP. Bevor sich Ihnen beim Lesen dieses Abschnitts aber der Gedanke aufdrngt, L2TP sei eigentlich ein vllig unbrauchbares Protokoll zum Einsatz in ffentlichen Netzen, sollten Sie sich vor Augen halten, dass L2TP kein Sicherheitsprotokoll ist, dies niemals sein sollte und dies niemals sein wird. L2TP ist, der Name sagt es eigentlich schon,
303
ein reines Tunneling-Protokoll. Sicherheitsmanahmen werden auf anderen Ebenen eingesetzt, auf der Transport- oder der Netzwerkebene (L2Sec, IPSec usw.) oder auf applikationsnahen Ebenen wie SSL, PGP usw. Aus diesem Grunde sind auch in L2TP nur minimale Sicherheitsmechanismen eingebaut, die sich hauptschlich auf den Bereich der Control Connection und der Tunnelauthentifizierung beschrnken. Im Vergleich zu Sicherheitsprotokollen wie IP Security bietet L2TP keinen Schutz der Datenvertraulichkeit und der Datenintegritt, und es findet auch keine Paketauthentifizierung statt. Falls hierfr Bedarf vorhanden ist, dann wird vom L2TP-Standardisierungsgremium empfohlen, die Sicherheitsdienste der darunter liegenden Transportprotokolle zu benutzen, also im Falle von L2TP/UDP beispielsweise IPSec im Transport-Modus einzusetzen. Auf diese Weise wird die Verbindung zwischen LNS und LAC vollstndig also Steuerungs- und Datenkanle geschtzt. L2TP selbst bietet eine zugegebenermaen recht simple Authentifizierung von LNS und LAC beim Aufbau eines Tunnels. Diese Authentifizierung basiert auf einem dreiphasigen Handshake-Verfahren, hnlich wie CHAP, das die Existenz eines Shared Secret auf den beteiligten Gegenstellen voraussetzt. Dieses Shared Secret ist auch gleichzeitig der Schwachpunkt des Verfahrens, denn es wird in den meisten Implementierungen eine Kombination aus Buchstaben, Ziffern und Sonderzeichen im Klartext gespeichert. Somit besteht die Gefahr von Wrterbuchangriffen, Brute-Force-Attacken oder eines Angriffs auf den LAC oder LNS selbst, da das Shared Secret dort entweder direkt im Klartext gespeichert oder zumindest einfach rekonstruierbar ist. Als weitere Sicherheitsmanahme ist die Verwendung von Hidden-AVPs innerhalb der Steuerungsverbindung mglich, wie in Abschnitt 9.2.8 bei der Vorstellung des H-Bit erlutert wird. Diese im Vergleich zu Algorithmen wie DES oder IDEA eher rudimentre Verschlsselung ist leider mit einem berschaubaren Aufwand zu knacken. Man muss sich lediglich das Shared Secret beschaffen (siehe oben) und kann damit den benutzten 128-Bit-Schlssel berechnen, oder man startet eine Kryptoanalyse auf das Ergebnis der Exklusiv-Oder-Verknpfung, die in L2TP als Ver- und Entschlsselungsalgorithmus verwendet wird. Im Gegensatz beispielsweise zum PPTP hat man beim Design von L2TP darauf verzichtet, bestimmte Dienste oder Funktionen an darunter liegende Protokolle zu binden. So werden Pakete des Steuerungskanals im PPTP aus Grnden der Verlsslichkeit ber TCP transportiert, Datenpakete dagegen ber UDP. L2TP ist dagegen ein so genanntes self containing protocol, also ein Protokoll, dass vllig unabhngig von den darunter liegenden Schichten arbeitet. L2TP kann daher auf UDP/IP, Frame Relay, ATM usw. aufsetzen. Die Zuverlssigkeit, die PPTP durch die Verwendung von TCP erreicht, ist im L2TP-Protokoll selbst implementiert. Der Verzicht auf TCP birgt zugleich aber auch einen wichtigen Sicherheitsvorteil. Denn das TCP-Protokoll ist gegen eine Reihe von protokollspezifischen Angriffen anfllig: die so genannten Denial-of-Service-Angriffe. Beim Einsatz von UDP ist man davor geschtzt.
304
IPSec secured L2TP
9.4
IPSec secured L2TP
Falls man L2TP in IP-Umgebungen wie dem Internet oder den Backbones von Service Providern einsetzt, ist IPSec das empfohlene Verfahren, um die notwendige Sicherheit zu gewhrleisten. Durch die Entscheidung von Microsoft, dieses Verfahren (IPSec secured L2TP oder kurz L2TP/IPSec) als Basis seiner VPN-Technologie in Windows 2000 einzusetzen, ist es mit einem Schlag sehr populr geworden. Zugleich markiert es auch die Abkehr Microsofts vom jahrelang bevorzugten PPTP und eine Hinwendung zu offenen Standards wie IP Security und L2TP. Durch diese Kombination von IPSec und L2TP beseitigt man entscheidende Schwachstellen in beiden Verfahren. IPSec ist ein sehr sicheres Protokoll, aber von seinem Design her ausschlielich auf Sicherheit ausgelegt mit der Option, einzig und allein IP zu tunneln. IPX und andere Protokolle bleiben auen vor. L2TP andererseits kann aufgrund seines Designs alle mglichen Protokolle tunneln, sofern sie in PPP einzukapseln sind. Aber L2TP bietet praktisch keine nennenswerten Sicherheitsfunktionen. Durch die Kombination beider Protokolle heben sich beide Schwchen gegenseitig auf, und man hat ein sehr flexibles Tunneling-Protokoll mit hchster Sicherheit.
Client ISDN RAC IP-Netz Gateway
IPSec
PPP
IPSec
L2TP
PPP L2TP
L2TP/IPSec
PPP PPP L2TP IPSec
Abbildung 9.16: IPSec, L2TP und L2TP/IPSec im Performance-Vergleich
305
Allerdings erkauft man sich diesen Vorteil zu einem hohen Preis. Sehen wir uns einmal in Abbildung 9.17 den Vergleich zwischen IPSec, L2TP und L2TP/IPSec als Basis eines einfachen VPNs an, und berschlagen wir den Aufwand (Rechenzeit, Speicher), den die beteiligten Systeme damit haben. Zum Rechnen nehmen wir als praxisnahes Beispiel einmal ein mittelgroes Unternehmen an, das im Schnitt 1.000 Benutzern gleichzeitig Remote Access gewhren will. Beim Vergleich der Protokolle sieht man Folgendes: IPSec Hier wird auf dem Client zustzlich zur PPP-Verbindung fr die Verbindung zum RAC noch das IPSec-Protokoll mit mindestens zwei IPSec-Sicherheitsassoziationen (SAs) terminiert. Der RAC des Service Providers terminiert 1.000 PPP-Verbindungen. Auf dem Gateway im Kundennetz werden ebenfalls 2.000 IPSec-SAs verarbeitet. L2TP L2TP erfordert auf dem Client gar keinen zustzlichen Aufwand, da der Tunnel erst im RAC des ISP initiiert wird. Der RAC unterhlt einen einzigen Tunnel zum LNS im Gateway des Kunden. Dort werden jedoch alle 1.000 PPPVerbindungen der Clients terminiert.
1000 Clients 1 RAC 1 Gateway
(Pro Client) PPP IPSec L2TP PPP IPSec L2TP PPP IPSec L2TP
IPSec L2TP L2TP/IPSec
1 1 2
1000 1 1000
2000 1
1000
1000 2000 1000
Abbildung 9.17: Die Protokollterminierungen bei einem Remote-Access-VPN mit IPSec, L2TP und L2TP/IPSec
L2TP/IPSec Hier wird der Begriff Ende-zu-Ende-VPN sehr ernst genommen, denn sowohl auf dem Client als auch auf dem Gateway des Kunden wird sehr viel an Verarbeitungsleistung bentigt. Auf dem Client werden gleich zwei PPP-Sessions terminiert, eine zum ISP und eine zum Gateway. Zustzlich terminiert ein virtueller LAC einen L2TP-Tunnel zum LNS im Gateway. Die beiden IPSecSAs runden das Ganze ab, auch sie mssen im Gateway terminiert werden.
306
IPSec secured L2TP
Der RAC terminiert 1.000 PPP-Sessions und nimmt weder an L2TP noch an IPSec teil. Auf dem Gateway werden dann aber 1.000 L2TP-Tunnel, 1.000 PPPSessions und 2.000 IPSec Security Associations terminiert! Man sieht also, dass L2TP/IPSec ein elegantes Verfahren darstellt, die Vorteile von L2TP und IPSec zu nutzen, ohne deren Nachteile in Kauf nehmen zu mssen, dass das ganze aber auch einen gewissen Preis hat. Denn ein System, das Tausende von PPP-Sessions, L2TP-Tunneln und IPSec-SAs gleichzeitig terminiert, bentigt eine ppige Ausstattung mit Rechenleistung und Speicher. Von dem Gedanken, ein herkmmlicher Router oder gar ein PC knnte dies mit angemessener Leistung tun, sollten Sie sich lsen. Hier sollten Sie spezielle Systeme einsetzen, die fr so etwas entwickelt wurden.
Client ISDN RAC IP-Netz Gateway
1. PPP-Verbindung 2. IPSec-Sicherheitsassoziation 3. L2TP-Tunnel 4. PPP-Session

5. IP, IPX, Kommunikation
IP
Daten
PPP IP
Daten
L2TP PPP IP
UDP L2TP PPP IP
Daten
Daten
IP
ESP
ESP
UDP L2TP PPP IP

UDP L2TP PPP IP
Daten
Daten
ESP
ESP
PPP IP
Abbildung 9.18: Die Funktionsweise von L2TP/IPSec beim Erzeugen eines ausgehenden Pakets
Nachdem nun klar ist, worauf Sie sich einlassen, folgt hier ein kurzer berblick, wie L2TP/IPSec nun eigentlich funktioniert. Zwischen dem L2TP/IPSec-Client und dem Gateway muss zuerst eine IP-Verbindung aufgebaut werden. Der Client baut hierzu eine PPP-Verbindung zum RAC auf. Zwischen Client und
307
Gateway wird dann eine IPSec-Verbindung etabliert, und anschlieend kann ber diese sichere Verbindung ein L2TP-Tunnel aufgebaut werden, durch den nun die privaten Netzwerkpakete in PPP-Frames transportiert werden knnen. Die in der Abbildung 9.18 dargestellte Paketverarbeitung luft nun wie folgt ab: Die IP-Pakete werden in PPP-Frames eingekapselt. Diese PPP-Pakete werden anschlieend in L2TP-Datenpakete gekapselt und diese wiederum in UDP/IP-Pakete eingepackt. Um diese Pakete herum wird ein IPSec-Header und -Trailer konstruiert, die Daten werden verschlsselt, und es wird ein Message Authentication Code (MAC) berechnet. Anschlieend wird das Paket nochmals in PPP gekapselt und kann nun zum Einwahlkonzentrator des Service Providers geschickt werden. Dies ist nicht nur eine recht aufwendige Verarbeitung, auch der Paket-Overhead kann sich im Vergleich zur Nutzlast, dem originalen IP-Paket, sehen lassen. Aber wie gesagt, bei Kenntnis des Sachverhalts und einer davon ausgehend vernnftigen Auslegung der Komponenten und ihrer Leistungsfhigkeit hat man die Mglichkeit, in den Genuss der Sicherheit von IPSec zu kommen und trotzdem auch Nicht-IPPakete bertragen zu knnen.
308
10
VPN-Design
Das Design eines virtuellen privaten Netzwerks ist nicht leichter oder schwerer als das eines mit Standardtechnologie aufgebauten Netzes. Nach meiner mehrjhrigen Erfahrung mit IP-VPNs in mittlerweile sehr vielen, teilweise international ttigen Unternehmen waren es meist weniger praktische Probleme, mit denen die Planer und Betreiber von VPNs zu kmpfen hatten. Vielmehr war es oft eine gewisse Unsicherheit gegenber dem Thema Datensicherheit und den damit verbundenen Technologien wie der Kryptologie. Hier treffen ja auch zwei Welten aufeinander: Der klassische Netzwerker will ein mglichst hohes Ma an transparenter Kommunikation, und der Sicherheitsverantwortliche will genau das Gegenteil, nmlich eine nach verschiedenen Kriterien eingeschrnkte Kommunikation. Bisher konnten die Gegenstze organisatorisch getrennt werden; die Netzwerker bauten ihre privaten Netze, und die Verbindung zur ffentlichkeit, meist in Form des Internets, erfolgte in aller Regel ber eine Firewall. Mit dem Aufkommen der InternetVPNs wurde diese Trennung aufgehoben, und beide Seiten mssen sehr eng zusammenarbeiten und sich auf Kompromisse einigen, was in manchen Fllen allerdings auch zu Konflikten fhren kann.
10.1 Ein VPN ist auch nur ein Netzwerk

Mit diesem Leitsatz, der bis auf wenige Ausnahmen durchgehend anwendbar ist, kann man sich sein Leben als VPN-Planer sehr erleichtern. Der Trick dabei ist einfach der, dass man sich an genau die gleichen Kriterien hlt, die auch beim Design eines Routernetzwerks und einer Remote-Access-Lsung gelten. Die Sicherheitsstrategie gilt auch fr solche Netze, denn auch sie benutzen ffentliche Netze wie ISDN, Frame Relay oder ATM. Der Unterschied ist einfach nur, dass das ffentliche Netzwerk jetzt Internet heit und ein Netzwerk mit virtuellen Verbindungen auf der Netzwerkschicht des OSI-Modells vorliegt. So viel zur Theorie. Die Wirklichkeit sieht, wie Sie wissen, leider etwas anders aus, denn in sehr vielen Organisationen wurde die Sicherheitsstrategie, die bei Internet-VPNs pltzlich zum K.o.-Kriterium aufgestiegen ist, berhaupt nicht angewendet. Hand aufs Herz: Wer verschlsselt denn seine Dial-InRemote-Access-Verbindungen, wer verschlsselt seine Frame-Relay- oder ATM-PVCs? Nach vorsichtigen Schtzungen anhand dessen, was die RouterMarktfhrer umgesetzt haben, sind deutlich weniger als 1% aller WAN- und Remote-Access-Verbindungen durch Verschlsselung gegen Verletzungen der Datenvertraulichkeit geschtzt! Und das, obwohl alle Telefonnetze
309
10 VPN-Design
gesetzlich zur Bereitstellung von Abhreinrichtungen verpflichtet sind. Natrlich darf das nur mit einer richterlichen Genehmigung erfolgen, aber die Gefngnisse sind voll von Leuten, die Gesetze gebrochen haben. Und pikanterweise ist es, technisch gesehen, wesentlich einfacher, eine Kommunikation ber ein leitungsvermittelndes Medium wie ISDN, Frame Relay oder ATM abzuhren, als wenn diese ber ein echtes, rein paketvermittelndes IPNetz wie das Internet erfolgt. Fakt ist also, dass im Bereich der herkmmlichen WAN-Infrastruktur nichts von dem getan wurde, was viele Sicherheitsstrategien fr die Datenkommunikation ber ffentliche Netze fordern. Man hat einfach Augen und Ohren verschlossen und Verbindungen wie Standardfestverbindungen oder FrameRelay-PVCs kurzum als privat eingestuft. Dies muss aber sptestens beim Thema Internet-VPN korrigiert werden, da hier keine spitzfindigen Formulierungen mehr gegen die Zeitungs- und Nachrichtenbeitrge helfen, die die Entscheidungstrger in den Unternehmen zum Thema Viren und andere Gefahren aus den Tiefen des Internets fast tagtglich zu lesen und zu hren bekommen. Allerdings kann man das Thema Sicherheit in der Planungsphase zeitlich etwas nach hinten verschieben, und zwar bis zur Auswahl der Tunnelingund Sicherheitsprotokolle. Bis dahin kann man mit einfachen Analogien arbeiten und die virtuellen Verbindungen ganz einfach wie reale Verbindungen oder andere virtuelle Verbindungen, wie sie in ATM oder Frame Relay verwendet werden betrachten, und sein Design entsprechend aufsetzen.
10.2 Die Planung

640 Kbyte sind genug. Dieser Ausspruch, es ist kaum zu glauben, stammt von Microsoft-Grnder Bill Gates und verdeutlicht sehr gut das mittlerweile allseits bekannte Dilemma, dass man heute in der Informationstechnologie keine wirklich verlsslichen Zukunftsprognosen stellen und diese zur Grundlage fr eine langfristige Planung machen kann. Die Planung eines VPN ist jedoch ebenso kritisch wie die Planung eines normalen Netzwerks, denn hier werden meist relativ langfristige Entscheidungen gefllt und auch die damit verbundenen Investitionen gettigt.
10.3 Die Ist-Aufnahme

Die Ist-Aufnahme ist ein sehr wichtiger Prozess, der neben seiner Bedeutung fr eine solide Planung auch wichtige Erkenntnisse ber den tatschlichen Zustand eines Netzwerks vermittelt. Aus dem Ergebnis lassen sich nebenbei auch Informationen fr andere Projekte im Bereich der LAN-Technologie und
310
Die Ist-Aufnahme
fr andere Netzwerkbereiche gewinnen. Natrlich bietet die Ist-Aufnahme auch eine gute Gelegenheit, die Netzwerkdokumentation wieder einmal auf einen aktuellen Stand zu bringen, da diese nicht selten der Wirklichkeit etwas hinterherhinkt. Ein Fehler ist dabei aber unbedingt zu vermeiden, nmlich Dinge in die IstAufnahme eines Netzwerks aufzunehmen, die keinerlei Beitrag zur Funktion des Netzwerks leisten. Das erhht zwar den Aufwand der Ist-Aufnahme, macht sie aber auch erst zu einer solchen. Ein Beispiel: Ein WAN-Router sei mit einer Software ausgestattet, die verschiedene Routingprotokolle fr IP, IPX, AppleTalk und VinesIP untersttzt; es werden aber nur IP (mit OSPF) und IPX (mit IPX-RIP) geroutet. Eine korrekte Ist-Aufnahme weist dieses Gert als Router mit OSPF und IPX-RIP und einer Option fr AppleTalk und VinesIP aus. Warum ist diese anscheinende Wortklauberei so wichtig? Ganz einfach: Aus der Ist-Aufnahme wird zusammen mit dem Sollzustand letztendlich ein Anforderungskatalog erstellt, auf dessen Basis die neu zu beschaffenden Systeme ausgewhlt werden. Wenn der Router jetzt als System, das IP, IPX, VinesIP und AppleTalk routet, aufgenommen worden wre, msste das neue System ebenfalls alle diese Features untersttzen, obwohl der Sollzustand dies vielleicht gar nicht fordert. Der Grund dafr ist die Migrationsphase, whrend der beide Welten fr einen gewissen Zeitraum nebeneinander existieren mssen. Im anderen, korrekten Fall wrde man jedoch sehen, dass im Augenblick kein VinesIP und AppleTalk bentigt wird, dass es in Zukunft (Sollzustand) ebenfalls nicht bentigt wird und somit in den neuen Systemen berflssig ist und damit auch nicht beschafft und bezahlt werden muss. Fr ein kleines Netzwerk, dessen Topologie der Netzwerkadministrator ohnehin komplett im Kopf hat, mag dies vielleicht noch etwas bertrieben scheinen. Aber sobald die Anzahl der Router zwei-, drei- oder sogar vierstellig ist, die Gerte auf weit auseinander liegende Standorte verteilt sind und die Inventarisierung von verschiedenen Personen durchgefhrt wird, kommt man um eine strukturierte, gut vorbereitete Ist-Aufnahme und -Auswertung nicht mehr herum. Was ist bei der Ist-Aufnahme nun alles zu ermitteln? Es mssen sowohl technische als auch betriebswirtschaftliche Erkenntnisse gesammelt und aufbereitet werden, nicht zuletzt deshalb, um das tatschliche Ratiopotenzial eines VPN beurteilen zu knnen. Hier kann es das sei an dieser Stelle nicht verschwiegen, obwohl es kein Thema dieses Buches ist zu Konflikten mit der Arbeitnehmervertretung kommen. Denn wenn man Daten sammelt, die Auskunft ber das Verhalten von Benutzern geben knnen, ist der Betriebsrat in aller Regel zustimmungspflichtig. Dies gilt insbesondere fr Verkehrsanalysen. Hier sollte also rechtzeitig mit dem Betriebsrat gesprochen werden, um Konflikte von vornherein zu vermeiden.
311
10 VPN-Design
10.3.1
Hardware
Technische Aspekte
Neben einer reinen Hardwareinventur der Router, Switches, Hubs, Remotebridges, Remote-Access-Konzentratoren, Firewalls und Workstations fr Netzwerkmanagement-Applikationen sollte auch eine Funktionsbeschreibung und Abschtzung der aktuellen Leistungsfhigkeit erfolgen. Man muss ermitteln, was wo installiert ist, wozu es benutzt wird und benutzt werden kann, was es leistet (Durchsatz, QoS) und inwieweit es erweiterbar ist. In unserem Fall ist es dabei gar nicht mal als schlecht zu bewerten, wenn es sich herausstellt, dass bei einem weiteren Wachstum des Netzwerks bestimmte Gerte das Ende ihrer Verwendbarkeit bereits erreicht haben. Auch hier ist es notwendig, nicht benutzte Module oder Schnittstellen zu kennzeichnen. Software Hierbei gilt es, die auf den inventarisierten Netzwerksystemen installierte Software und weitere Programme zu ermitteln, die eine bestimmte Netzwerkfunktionalitt ausben, beispielsweise Netzwerkmanagement-Applikationen, Dial-In-Clients, DHCP- und DNS-Server, Konfigurationstools usw. Neben der reinen Inventarisierung sollte auch die tatschlich benutzte Funktionalitt hervorgehoben werden und nur diese, denn Features oder Module, die (aus welchen Grnden auch immer) nicht benutzt werden, drfen bei einer Ist-Aufnahme keine Rolle spielen. Man kann sie zwar aufnehmen, sollte dies auch tun, muss sie aber entsprechend kennzeichnen. Netzwerkprotokolle Es wird nicht selten vorkommen, dass eine ganze Reihe unterschiedlicher Netzwerkprotokolle in lokalen Netzwerken eingesetzt wird. Im WAN-Umfeld werden aus verschiedenen Grnden oft nur wenige Protokolle verwendet, meist IP, gefolgt von IPX und seltener AppleTalk, VinesIP und Hostprotokollen wie SNA. ber den Sinn oder Unsinn einer solchen Protokollvielfalt muss man sich erst spter, bei der Definition des Sollzustands, Gedanken machen. Bei der Aufnahme der Protokolle es ist auch wichtig, ein Mengengerst aufzustellen, aus dem man ablesen kann, wie viele Benutzer und Applikationen die betreffenden Protokolle berhaupt einsetzen. Verbindungen Hierbei geht es um die Aufstellung aller Verbindungen und Verbindungstypen mit ihren technischen Mglichkeiten. Es sind hierbei erst einmal all die Parameter aufzunehmen, die die jeweilige Technologie kennzeichnen, also Werte
312
Die Ist-Aufnahme
wie maximal zur Verfgung stehende Bandbreite, garantierte Bandbreite, Verzgerung, Verfgbarkeit, Serviceklassen usw. An dieser Stelle kann zu Planungszwecken auch die Mietdauer der Leitung oder Verbindung mit angegeben werden, um spter daraus einen geeigneten Migrationsplan abzuleiten und gegebenenfalls fristgerecht bestimmte Leitungen kndigen zu knnen. Unter diesen Punkt fallen auch Whlverbindungen oder genauer gesagt: die Verbindungen der Remote-Access-Konzentratoren zu einem Carrier. Verkehrsbeziehungen Dieser Punkt verdient eine besondere Beachtung, denn er bietet in Verbindung mit der zu installierenden VPN-Technologie einen guten Ansatzpunkt zur Optimierung des Netzwerks also dafr, mehr Leistung fr weniger Geld zu bekommen. Denn wenn man aus der Anzahl und Art der bisher existierenden Verbindungen die Anforderungen an die virtuellen Verbindungen eines VPN ableitet, liegt man sehr oft grndlich falsch. Denn wenn Sie beispielsweise aus der Tatsache, dass zwei Niederlassungen ber eine 128-Kbit/s-Festverbindung verbunden sind, ableiten, eine virtuelle Verbindung ber ein IP-VPN msse mit garantiert 128 Kbit/s arbeiten, drfe nur eine unvernderliche Verzgerungszeit von wenigen Millisekunden aufweisen und habe 99,999% Verfgbarkeit zu bieten, ist das schlicht falsch! Hier kann nur eine Analyse helfen, und je grndlicher diese ist, desto besser knnen Sie spter Ihre Anforderungen in einem Service Level Agreement formulieren. Ein detailliertes Verkehrsprofil hilft aber nicht nur dabei, denn wenn Sie das ganze Netzwerk mit einbeziehen, knnen Sie auch wichtige Erkenntnisse fr den vielleicht geplanten Einsatz von Quality-of-Service, Policy-Services usw. erhalten oder einfach nur Ihr Netzwerk etwas anders strukturieren oder segmentieren. Solch eine Analyse ist nicht trivial. Es gilt eine gewaltige Datenflut zu sammeln, auszuwerten und so aufzubereiten, so dass man daraus entsprechende Manahmen ableiten kann. Es mssen sowohl zeitliche Abhngigkeiten als auch Abhngigkeiten von Protokollen und Applikationen ermittelt werden. Sie mssen die Frage beantworten knnen, welche Applikationen zu welchen Zeiten ber ein WAN welche Art von Datenverkehr erzeugen. Sie knnen, als Vorgriff auf eine spter vorzunehmende Priorisierung, die Datenstrme hier bereits in verschiedene Klassen einteilen. Dies gilt sowohl fr permanente Verbindungen als auch fr den Remote Access ber analoge oder digitale Whlverbindungen.
313
10 VPN-Design
Benutzerklasse Heimbro Auenstelle Auendienst Allgem. Remote Access
Anzahl 45 10 236 400
Std/Wo 1.900 540 154 123
Nah % 35 22 34 62
Fern % 65 78 48 26
Int % 0 0 18 12
Gbyte 0,9 2,1 1,6 2,7
Tab. 10.1: Ein Beispiel fr ein mgliches Remote-Access-Verkehrsprofil
Im Remote-Access-Bereich muss eine solche Analyse nicht unbedingt fr alle Verbindungen erfolgen, hier kann man sich einen allgemeinen berblick verschaffen. Hierbei knnen Sie, wie Sie in Tabelle 10.1 sehen, fr die unterschiedlichen Arten von Benutzern der Remote-Access-Infrastruktur ermitteln, wie das entsprechende Profil aussieht. Das in Einwhlumgebungen in der Regel eingesetzte RADIUS-Accounting kann sehr wertvolle Informationen liefern. In Tabelle 10.1 wurde eine Auswertung des Accounting ber eine Woche vorgenommen. Da hier kein Personenbezug existiert, drften solche Auswertungen auch betriebsrechtlich problemlos mglich sein. Verbindungsprofile kann man in diesem Beispiel ebenfalls ermitteln, indem man stichprobenartig ein entsprechendes Monitoring von Verbindungen der verschiedenen Remote-Access-Benutzerklassen durchfhrt. Weiterhin interessant sind Gesamtauswertungen der Verbindungsanzahl ber den Tag hin gesehen, um die bentigte Anzahl virtueller Ports zu ermitteln.
10.3.2
Betriebswirtschaftliche Aspekte
Gettigte Investitionen und Restwerte Je nachdem welches Equipment durch die neuen VPN-Systeme ersetzt werden soll, kann es sein, dass diese Gerte noch einen gewissen Restwert haben. Dies hngt im Wesentlichen vom Beschaffungsdatum und der Abschreibungsdauer ab. Insbesondere wenn relativ neue Router oder Remote-AccessKonzentratoren ersetzt werden sollen, muss dieser Wert in eine entsprechende ehrliche Wirtschaftlichkeitsrechnung mit einflieen. Kosten fr Datenverbindungen Die Kosten, also die Bereitstellungsgebhren, regelmigen Fixkosten und die volumen- oder zeitabhngigen Tarife des Carriers sind entsprechend aufzunehmen. Es ist sinnvoll, auch eine Unterteilung nach Art der Kosten vorzunehmen, um zu sehen, wie hoch die Leerlaufkosten, also die Kosten ohne bertragene Daten, des Netzwerks sind. Denn genau dies ist ein Faktor, den man tunlichst nach unten drcken sollte, damit man mglichst nur fr die tat-
314
Die Ist-Aufnahme
schlich bertragene Datenmenge bezahlt. Ganz weg bekommt man Grundgebhren im Augenblick leider nicht, auch dann nicht, wenn man ein VPN einsetzt, aber man kann den Anteil ruhig so weit reduzieren, wie es nur irgendwie mglich ist. Wartungs- und Betriebskosten Hierbei handelt sich um alle Kosten, die der Betrieb des Netzwerks verursacht, auer den Gebhren fr die Datenverbindungen und die Personalkosten. Unter die Betriebskosten fallen also Kosten fr Wartungsvertrge mit Zulieferern, Carriern und Servicefirmen und eine Schtzung von auergewhnlichen Kosten, die auf den bisher dafr angefallenen Kosten beruht. Personalkosten Neben den reinen Aufwendungen fr Gehlter und Sozialleistungen mssen hier auch die Kosten fr Qualifikationsmanahmen fr die Mitarbeiter mit einbezogen werden. Auch hier gilt: Nicht in die Tasche lgen und den wirklichen Personalaufwand ermitteln. Denn oftmals nehmen manche Personen verschiedene Aufgaben in verschiedenen Bereichen wahr, und man muss daher sehr genau feststellen, welchen tatschlichen Zeitaufwand der Betrieb zurzeit bentigt. Hier sollte mglichst kein Personenbezug erfolgen, sondern der echte Zeitaufwand fr den Netzwerkbetrieb in Manntagen ermittelt werden.
10.3.3
Sicherheit
Datenvertraulichkeit im WAN Die Aufstellung, die hier zu machen ist, soll Auskunft darber geben, welche WAN-Verbindungen (Standardfestverbindungen, Mietleitungen, Frame Relay, ATM, Whlverbindungen ber ISDN, Modem, GSM usw.) verschlsselt sind. Weiterhin mssen die Strke der Verschlsselung, das eingesetzte Verfahren und das Schlsseltauschprotokoll oder die Qualitt der Schlssel (Lebensdauer usw.) angegeben werden. Authentifizierung Hier mssen alle netzwerkbezogenen Verfahren und Systeme zur Authentifizierung von Benutzern beschrieben werden. Nicht mit einbezogen werden natrlich Anmeldungen an Applikationen oder Betriebssystemen. Besonderes Augenmerk ist dabei naturgem auf den Remote Access zu legen.
315
10 VPN-Design
Autorisierung Falls Anwender auf Netzwerkebene, abhngig von ihrer User-ID (oder anderen persnlich zuordenbaren Kennzeichen), der verwendeten Arbeitsstation oder des Orts des Zugriffs, unterschiedliche Benutzerrechte zugewiesen bekommen, mssen diese ebenfalls aufgenommen und beschrieben werden, um spter entsprechende Anforderungen ableiten zu knnen. Allerdings sollten solche Rechte wenn mglich von den Systemen vergeben werden, die diese Ressourcen auch verwalten, zum Beispiel von Netzwerkbetriebssystemen oder Datenbankmanagementsystemen. Zugriffsrechte auf Ressourcen wie Datenbanken, Drucker oder Dateiverzeichnisse von Routern oder Remote-Access-Konzentratoren verwalten zu lassen, ist ein falscher Ansatz. Andere Sicherheitsverfahren Im Fall, dass darber hinaus noch weitere Sicherheitsverfahren auf Netzwerk- oder Transportebene eingesetzt werden, mssen diese so beschrieben werden, dass daraus die mglichen Berhrungspunkte zu den neu einzusetzenden Systemen erkannt und bercksichtigt werden knnen.
10.4 Der Sollzustand

Der Sollzustand beschreibt das Netzwerk so, wie es nach der Einfhrung der VPN-Lsungen aussehen soll. Mit einer guten, realistischen Planung ist dieser Zustand auch grundstzlich erreichbar. Einzig das Mengengerst ist der typische Wackelkandidat in der Planung, denn meist wachsen die Anforderungen an die Anzahl von Netzwerk- oder Remote-Access-Ports und der Durst nach immer mehr Bandbreite doch schneller, als ursprnglich angenommen wurde. Eine zu optimistische Schtzung fhrt auch meist zu hheren Anfangsinvestitionen, die man in der Regel vermeiden mchte, um das Projekt nicht unntig zu gefhrden.
10.4.1
Der unvermeidliche(?) Bruch
In der Vergangenheit bin ich whrend verschiedener Workshops und Seminare fr Kunden und Partnerfirmen oft mit miteinander unvereinbaren Forderungen konfrontiert worden, die meist darauf hinausliefen, dass bestimmte Protokolle, die im Augenblick (noch) eingesetzt wurden, auch im Sollzustand, also im VPN zu untersttzen seien. Die Forderung, IPX-Pakete mit IPSec zu bertragen, ist ein typischer Fall hierfr. Obwohl dies mittlerweile durch Kombinationen verschiedener Protokolle (allerdings mit einem betrchtlichen Overhead, siehe Kapitel 9) mglich ist, gab es vor zwei Jahren nur recht umstndliche Lsungen, meist mit mehreren beteiligten Systemen oder man musste auf IPX, zumindest im IPSec-VPN-Teil, verzichten.
316
Der Sollzustand
Solche Brche sind aber nicht selten, genau genommen kommen sie in der Praxis ziemlich oft vor. Insbesondere der Krieg der Protokolle, aus dem der Veteran IP als unbestrittener Sieger hervorgegangen ist, hat seine Spuren hinterlassen kaum ein Hersteller bercksichtigt noch auf der Strecke gebliebene Protokolle wie VinesIP, DECNet oder XNS in seinen Neuentwicklungen, selbst AppleTalk wird immer seltener; und die Internet Engineering Task Force (IETF) hat es noch nicht einmal entfernt in Betracht gezogen, sich bei der Standardisierung von IPSec mit IPX zu beschftigen. Andere Protokolle, wie NetBEUI oder NetBIOS, haben sich durch ihre LAN-Lastigkeit und mangelnde Skalierbarkeit ihr eigenes Grab geschaufelt und werden nur noch durch die Dominanz von Microsofts Desktop-Betriebssystemen knstlich am Leben gehalten. Die daraus resultierenden, unvermeidlichen Brche ergeben sich also nicht unbedingt aus einer mangelnden Funktionalitt der neuen Systeme, sondern spiegeln eher die Tendenz wider, im Netzwerkbereich eine weit reichende Protokollbereinigung zugunsten von IP vorzunehmen. Das macht auch Sinn. Denn wenn sich die Hersteller, anstatt zwanzig verschiedene Netzwerkprotokolle zu untersttzen, darauf fixieren, nur IP allerdings mit allen wichtigen und neuen Funktionalitten wie Sicherheit, Class-of-Service usw. zu implementieren, bringt das viel mehr an nutzbarer Funktionalitt. Viele Unternehmen haben sich sowieso bereits seit einiger Zeit entschlossen, ihren Protokoll-Zoo langsam abzubauen und zuknftig nur noch IP einzusetzen. Die Einfhrung der VPN-Technologie wre ein guter Zeitpunkt dafr. Andere Brche sollten so weit wie mglich vermieden werden, um den Betrieb nicht unntig zu beeintrchtigen. Im Einzelfall sollte man im Vorfeld sehr genau untersuchen, ob der Verzicht auf bestimmte Funktionalitten zumutbar oder tragbar ist und welche Alternativen zur Verfgung stehen. Setzt ein Unternehmen beispielsweise fr den Remote Access bereits Tokensysteme wie SecurID ein und hat es vielleicht schon mehrere Tausend Karten im Einsatz, dann ist ein Verzicht darauf oder eine Ablsung durch ein anderes System in der Regel indiskutabel hier muss eben eine andere VPN-Technologie eingesetzt werden, die dieses Authentifizierungssystem untersttzt.
10.4.2
Randbedingungen
In die Planung eines VPN fliet eine Vielzahl von Kriterien ein, und es sind verschiedene Randbedingungen und Prmissen zu beachten. Neben den natrlichen Anforderungen an ein VPN, auf die in Kapitel 3 ausfhrlich eingegangen wurde, gibt es eine Reihe anderer Faktoren, die den angestrebten Sollzustand beeinflussen:
317
10 VPN-Design
Andere Netzwerkprojekte Die Einfhrung der VPN-Technologie ist in der Regel nicht das einzige aktuelle Projekt im Netzwerkbereich eines Unternehmens. Andere Projekte knnen durchaus einen natrlich auch wechselseitigen Einfluss ausben. Ein Beispiel, auf das aus gutem Grund in diesem Buch bereits mehrfach eingegangen wurde, ist die Einfhrung von Quality-of-Service, um das Netzwerk effizienter ausnutzen zu knnen. Hier muss einerseits die VPN-Technologie auf QoS ausgelegt werden, und andererseits mssen die QoS-Planer auch bercksichtigen, dass ihr Unternehmensnetzwerk zuknftig streckenweise das Internet benutzt, mit je nach Service Provider mglicherweise eingeschrnkter QoS-Funktionalitt. Neue Applikationen Moderne netzwerkbasierende verteilte Applikationen ben einen zunehmend strkeren Einfluss auf das Design von Unternehmensnetzen aus. Neben einem immer grer werdenden Bedarf an Bandbreite sind auch zunehmend Qualittskriterien wie Verzgerungszeiten und Variationen der Paketverzgerung (Jitter) im Anforderungskatalog an das Netzwerk mit aufgefhrt. Insbesondere wenn teure internationale Meetings durch Videokonferenzen ersetzt werden sollen oder wenn ber IP-Netze telefoniert wird, wird der Netzwerkplaner mit Anforderungen konfrontiert, die in der reinen Datenwelt bislang unbekannt waren. Neue Standorte Dieser Punkt fliet dergestalt in die Planung des Sollzustands ein, als dass hier genau festgelegt wird, wie zuknftige neue Standorte in das VPN zu integrieren sind. Es mssen alle Informationen bereitgestellt werden, um die notwendigen Schritte, wie Beschaffung der Systeme, Bereitstellung der Internetzugnge usw., schnell und reibungslos durchfhren zu knnen. Neue Geschftsmodelle (E-Business usw.) Neue Geschftmodelle knnen ebenfalls einen starken Einfluss auf den Sollzustand des Netzwerks bzw. des VPNs haben insbesondere dann, wenn die VPN-Technologie benutzt werden soll, um die geschftliche Kommunikation mit Dritten zu schtzen: der klassische Fall eines Extranet-VPN. Ein anderer Fall wre beispielsweise der, dass ein greres Unternehmen Teile seines eigenen Netzes Kunden oder Partnern zur Verfgung stellt, also praktisch selbst zu einem kleinen Service Provider wird. Auf diese Weise knnen ansonsten brachliegende Ressourcen Gewinn bringend genutzt werden.
318
Der Sollzustand
10.4.3
Technische Aspekte
Wie der Sollzustand aus technischer Sicht im Einzelnen auszusehen hat, richtet sich nach einer Vielzahl von Faktoren. Hier kann auch kein allgemein gltiges Beispiel gegeben werden, denn der Durchdringungsgrad der VPN-Technologie kann sehr unterschiedlich sein und von einem totalen VPN bis zum Einsatz einiger weniger Remote-Access-VPN-Clients reichen. Bei der groen Dynamik heutiger Netze kann es sogar sinnvoll sein, berhaupt keinen fixen Sollzustand als solchen zu definieren, sondern nur ganz konkrete Richtlinien aufzustellen, mit welcher Art von Komponenten das Netzwerk zu erweitern ist. In einem solchen Fall stellt man einen Plan auf, wodurch und in welcher Reihenfolge die Altsysteme zu ersetzen sind und welche Systeme fr neue Standorte oder neue Dienste einzusetzen sind. Diese Festlegungen mssen eine Reihe von Punkten genau erfassen: Hardware Software Provider und Service Level Agreements Aktuelle Liste zugelassener Gertetypen Hardware Hiermit ist weniger der Gertetyp eines bestimmten Herstellers gemeint, sondern eine allgemeine Klassifizierung der einzusetzenden VPN-Systeme, unterschieden nach Einsatzgebiet (Remote-Access-, Branch-Office- oder Extranet-VPN) und bentigten Systemressourcen. Diese hngen in BranchOffice-VPNs meist von der Gre der Standorte ab, whrend im RemoteAccess-VPN die Anzahl der Benutzer und die Bandbreite interessieren, die durch die Art der verwendeten Zugangstechnologie (Modem, ISDN, DSL) bentigt wird. Software Hier ist von speziellen Stand-Alone-VPN-Applikationen die Rede, also beispielsweise von IPSec-Clients fr die PCs oder Notebooks von Auendienstmitarbeitern. Hier ist zu beachten, dass die Hardware auch mit der zustzlichen Verarbeitungsleistung fertig wird, die die Verschlsselungsprogramme bentigen. Manche IPSec-Clients lassen sich berhaupt nur auf Rechnern installieren, die mindestens einen Pentium-I-Prozessor eingebaut haben. Hier ein wichtiger Tipp fr internationale Anwendungen: Nicht alle Staaten erlauben es Privatleuten, ihre Daten- oder Sprachkommunikation beliebig zu verschlsseln. Bei der ganzen Diskussion um Exportbeschrnkungen (vor allem aus den USA) in den letzten Jahren wurde etwas anderes aus den Augen verloren, nmlich dass bestimmte Lnder den Betrieb, die Einfuhr
319
10 VPN-Design
oder sogar schon den Besitz von Verschlsselungssystemen teilweise empfindlich bestrafen. Hier sollte zum Schutz der Mitarbeiter unbedingt im Vorfeld abgeklrt werden, was in dem in Frage kommenden Land zulssig ist und was nicht! Provider und Service Level Agreements (SLA) Eine wichtige Entscheidung ist auch die, welcher oder welche Provider eingesetzt werden darf bzw. drfen. Man kann sich hier bereits auf bestimmte Unternehmen festlegen, falls es aus bestimmten Grnden sinnvoll erscheint. Man kann aber auch lediglich einen Rahmen vorgeben und es der jeweiligen Organisationseinheit oder Niederlassung berlassen, sich einen Provider auszusuchen, der in das technische Schema passt und im vorgegebenen Preisrahmen liegt. Hierbei sollte jedoch das SLA in den kritischen Teilen bereits bereits vorformuliert und nicht mehr nderbar sein. Integration in das Netzwerkmanagement Hier werden konkrete Vorgaben gemacht, welche Funktionalitten die Systeme bieten mssen, um in das bestehende oder geplante Netzwerkmanagement integriert werden zu knnen. Allerdings ist hier zu beachten, dass viele gute VPN-Systeme primr als Security-Gateways konzipiert sind und daher nur eine ganz eingeschrnkte SNMP-Funktionalitt bieten. Dies resultiert aus der praktisch nicht vorhandenen Sicherheit von SNMP. Aktuelle Liste zugelassener Gertetypen Es ist in jedem Fall angeraten, eine Liste von Systemen fr bestimmte Einsatzgebiete zu pflegen. Das Ganze kann als Tabelle gestaltet werden, die fr den Fall eines Remote-Access-VPNs etwa so wie in Tabelle 10.2 aussehen knnte.
Hersteller A 50 Benutzer 100 Benutzer 1000 Benutzer 5000 Benutzer Typ A-1 Typ A-1 Typ A-2 Typ A-3 Hersteller B Kein Produkt Kein Produkt Typ B-1 Typ B-2 Hersteller C Typ C-1 Typ C-2 Typ C-3 Typ C-4
Tab. 10.2: Eine Liste mit zugelassenen Remote-Access-VPN-Konzentratoren verschiedener Hersteller
In diesem Beispiel wurden verschiedene Produkte verschiedener Hersteller auf ihre Eignung untersucht und optional auch getestet. Bei Beschaffungsmanahmen entfllt dadurch viel an administrativem Aufwand. Im Idealfall haben die Finanz- und Einkaufsabteilung im Intranet ebenfalls Zugriff auf die Tabellen, und es kann das kostengnstigste Angebot ausgewhlt werden.
320
Der Sollzustand
10.4.4
Betriebswirtschaftliche Aspekte
Die betriebswirtschaftliche Sicht des Sollzustands muss sich durch eine Sache ganz besonders auszeichnen: Die Gesamtkosten mssen bei vergleichbarer Leistung und vergleichbarem Umfang des Netzwerks niedriger sein als die Kosten, die in der Ist-Analyse ermittelt wurden. Ansonsten stimmt etwas nicht in der Berechnung, oder das VPN erfllt seinen Hauptzweck nicht nmlich die Betriebskosten zu reduzieren. Falls im Sollzustand Erweiterungen des Netzwerks, neue Dienste, erweiterte Leistungen usw. hinzugekommen sind, sollten diese im Sinne einer mglichst hohen Transparenz getrennt ausgewiesen werden. Es muss in jedem Fall ein direkter Vergleich zwischen den Kosten der Ist-Aufnahmen und vergleichbarer Aufwnde im Sollzustand mglich sein. Die Kosten fr die Einfhrung bzw. den Umstieg auf die VPN-Technologie sollten Sie in jedem Fall mit in die Berechnung einbeziehen. Grob kann man zwischen folgenden Arten von Kosten unterscheiden, aus denen sich die tatschlichen Betriebskosten eines VPNs ergeben: Einmalige Kosten Laufende Kosten Personalkosten Einmalige Kosten Hier fallen insbesondere die Kosten fr die Investitionen in Soft- und Hardware sowie die Kosten fr Planung, Consulting und die Aufwnde fr die Installation des Equipments an. Hinzu kommen die Kosten fr die Bereitstellung der notwendigen Verbindungen, also der Leitungen zu den POPs des Service Providers. Laufende Kosten Hier entstehen feste Kosten durch monatliche Gebhren fr die bereitgestellten Verbindungen und Aufwendungen fr Wartungs- und Servicevertrge fr die eingesetzten Systeme. Weiterhin fallen noch variable Kosten fr die bertragenen Datenvolumina und verbrauchte Verbindungszeiten an. Personalkosten Die Personalkosten sind ein nicht unbetrchtlicher Faktor. Hier muss man nicht nur die direkten Kosten fr das VPN-Management mit einbeziehen, sondern muss auch die durch das VPN verursachten Kosten im Bereich des
321
10 VPN-Design
Benutzerservice (Help Desk) mit in Betracht ziehen. Gerade hier knnen, speziell im Bereich der Remote-Access-VPNs, durch eine nicht optimale Auswahl der VPN-Clientsoftware schnell sehr hohe Kosten auflaufen.
10.5 Die bergangsphase

Die bergangsphase ist ein ziemlich kritischer Punkt in einem VPN-Projekt, denn hier mssen ber einen bestimmten Zeitraum hinweg verschiedene Systeme fr den gleichen Dienst parallel betrieben werden, ohne dass sie sich gegenseitig stren drfen. Je nach dem Umfang des Unternehmensnetzwerks und des geplanten VPN kann eine solche bergangs- oder Migrationsphase recht lange dauern. Sie sollte in jedem Fall gut geplant werden, um spter die notwendigen Prozesse im Griff zu haben. Ausfhrliche Tests und Probelufe oder vielleicht abgegrenzte Pilotinstallationen, in denen man wichtige Erfahrungen fr den eigentlichen Umstieg gewinnen und spter umsetzen kann, knnen hier nicht schaden. Wenn man clever ist, kann eine Umstellung auf die VPN-Technologie sogar derart erfolgen, dass die Anwender fast nichts davon mitbekommen und sich in ihrer tglichen Arbeitsweise auch nicht gro umstellen mssen. Im Fall von Branch-Office-VPNs ist dies tatschlich mglich. Hier kann whrend eines Wartungsfensters der alte Router heruntergefahren werden und anschlieend das VPN-Gateway mit den gleichen IP-Adressen in Betrieb genommen werden. Die Benutzer bemerken davon gar nichts. Im Remote-Access-Bereich sieht die Sache etwas anders aus, da hier die Benutzer involviert sind. Auf deren Systemen mssen die VPN-Clients installiert werden, und sie haben sich statt im Firmennetz bei einem Provider einzuwhlen. Jedoch kann auch hier viel getan werden, beispielsweise mit automatischer Softwareverteilung und vorkonfigurierten Einwhlskripts. Dass die Benutzer auch im VPN ihre alten Benutzer-IDs, Passwrter, PINs oder Token-Karten weiterbenutzen knnen, versteht sich von selbst.
10.6 Die Sicherheitsstrategie

Die Sicherheitsstrategie des Unternehmens hat einen entscheidenden Einfluss auf das Design des VPN. Denn sie legt eindeutig fest, welche Sicherheit fr die Pakete, die ber ein ffentliches Netz transportiert werden, und fr die VPN-Systeme selbst gefordert ist. Nach ihr richten sich die Auswahl der Clientsoftware, der Authentifizierungssysteme und etwaige bauliche Manahmen denn ein VPN-Konzentrator, fr den man eine starke Verschlsselung
322
Die Sicherheitsstrategie
vorschreibt, kann nicht in einem Bro oder Verteilerraum betrieben werden , sofern die Security Policy konsistent umgesetzt wird. Fr die netzwerkseitige Planung eines VPN muss man, je nach den Vorgaben der Sicherheitsstrategie, in der Regel folgende Kriterien bercksichtigen: Welche Daten mssen geschtzt werden? Hier kann im Netzwerkbereich nicht viel getan werden, da der Inhalt der Daten nicht Gegenstand von Protokollen der OSI-Schichten 1 bis 4 ist. Man sollte jedoch den schlimmsten Fall annehmen, dass extrem sensible Informationen im VPN bertragen werden knnen auch wenn die Sicherheitsstrategie dies verbieten sollte. Wie lange mssen die Daten sicher sein? Man muss sich dagegen schtzen, dass ein Angreifer heute verschlsselte Daten aufzeichnet, die beispielsweise zehn Jahre vertraulich bleiben mssen, und diese vielleicht erst in fnf Jahren mit der dann zur Verfgung stehenden Technologie entschlsselt. Vor wem mssen diese Daten geschtzt werden? Die Frage ist, gegen welche Art von Angreifern man sich schtzen muss: Einzelpersonen, Gruppen, Firmen oder grere Organisationen oder im schlimmsten Fall Geheimdienste. Diesen Angreifern stehen unterschiedliche Ressourcen zur Verfgung, also muss man sich entsprechend stark schtzen. Leider kann man keine allgemein gltigen Aussagen darber machen, welche Verschlsselungsalgorithmen und Schlssellngen am besten einsetzbar sind. In Tabelle 10.3 und Tabelle 10.4 sehen Sie ein paar konservativ aufgestellte Faustregeln fr Schlssellngen von Public-Key-Verfahren und die korrespondierenden Schlssellngen von symmetrischen Verfahren. Es sollte immer ein ausgewogenes Verhltnis zwischen beiden Verfahren existieren, da die asymmetrischen Verfahren meist die Schlssel fr symmetrische Verfahren generieren oder austauschen. Es macht keinen Sinn, Daten mit 256-Bit-Schlsseln zu verschlsseln, die mit einem 512-Bit-Public-Key-Verfahren erzeugt wurden. Umgekehrt ist es auch ein sinnloser Aufwand, mit einer 2048-BitRSA-Verschlsselung einen symmetrischen 40-Bit-Schlssel auszutauschen.
Schutz vor Angriffen durch Personen 1024 Bit 1280 Bit 1280 Bit 1536 Bit Schutz vor Angriffen durch Organisationen 1280 Bit 1536 Bit 1536 Bit 2048 Bit Schutz vor Angriffen durch Geheimdienste 1536 Bit 2048 Bit 2048 Bit 2048 Bit
Schutzdauer 5 Jahre 10 Jahre 15 Jahre 20 Jahre
Tab. 10.3: Gebruchliche Schlssellngen fr Public-Key-Verfahren (RSA)
323
10 VPN-Design
Fr die Public-Key-Verfahren, die Sie in Tabelle 10.3 sehen, kommen praktisch keine kleineren Schlssellngen als 1024 Bit vor. Dies spiegelt den augenblicklichen Stand der Wissenschaft wider, versehen mit einer ordentlichen Sicherheitsreserve, um auch in der Zukunft vor bsen berraschungen sicher zu sein. Falls es die Performance der eingesetzten Systeme zulsst, kann man auch noch grere Schlssellngen whlen. Im Gegensatz zu symmetrischen Verfahren kann nmlich nicht so einfach bestimmt werden, mit welchem Aufwand Verfahren wie RSA zu brechen sind. Bei sicheren symmetrischen Verfahren ist der Aufwand eindeutig: Die Zeit, die ein Brute-Force-Angriff bentigt, steht in einem festen Verhltnis von Schlssellnge und eingesetzten Ressourcen (CPU-Geschwindigkeit, Arbeitsspeicher usw.). Bei Verfahren wie RSA kommt noch ein weiterer Faktor dazu, nmlich die weiteren, nicht vorhersagbaren Entwicklungen in der Zahlentheorie, speziell bei den Forschungen im Bereich Faktorisierung und diskrete Logarithmen. Beim IKE-Protokoll sollte man sich sorgfltig darber Gedanken machen, in welcher Kombination die Schlssellngen der eingesetzten Algorithmen Sinn machen. Der IPSec-Standard schreibt vor, dass DES mit 56 Bit Schlssellnge und Diffie-Hellman mit der Oakley-Gruppe 1 (768 Bit) zu untersttzen sind. Dies mssen also die eingesetzten IPSec-Systeme in jedem Fall untersttzen; die Kombination ist auch sinnvoll. Falls man aber eine hhere Sicherheit bentigt, als der DES-Algorithmus bietet und beispielsweise Triple-DES einsetzt, dann muss auch das IKE-Protokoll entsprechend angepasst werden und wenigstens die Oakley-Gruppe 2 mit einem 1024-Bit-Modulus verwendet werden. Ansonsten wre pltzlich das Schlsseltausch-Protokoll das schwache Glied in der Kette. Es nutzt nichts, eine starke Verschlsselung einzusetzen, wenn die Erzeugung des Schlssels, von dem ja die ganze Sicherheit abhngt, zu schwach ist.
Art der Daten Kurzfristige Vertraulichkeit Unternehmensergebnisse Langfristige Planungen Wirtschaftsgeheimnisse Personenbezogene Daten Schutzdauer mehrere Stunden mehrere Monate mehrere Jahre 10 bis 50 Jahre 50 Jahre und mehr Schlssellnge 56 Bit 64 Bit 80 bis 128 Bit 128 Bit >= 128 Bit
Tab. 10.4: Gebruchliche Schlssellngen fr symmetrische Verfahren (DES, IDEA, usw.)
In Tabelle 10.4 knnen Sie erkennen, dass eine symmetrische 128-Bit-Verschlsselung heutzutage auch fr hohe Sicherheitsanforderungen als ausreichend angesehen wird. Sichere symmetrische Verfahren (vgl. Kapitel 4) sind hinsichtlich ihrer Sicherheit relativ einfach zu bewerten. Da man den Aufwand fr die schnellstmgliche Kryptoanalyse (Brute-Force-Angriff) genau
324
Auswahl der VPN-Technologie
kennt, kann man sich durch entsprechend lange Schlssel auch gegen Angriffe von Geheimdiensten zuverlssig schtzen. Allgemein gelten Schlssellngen von 128 Bit bei einem sicheren Verfahren, z.B. Triple-DES, als nicht mehr knackbar. Der Rijndael-Algorithmus wird als Advanced Encryption Standard (AES) vermutlich noch im Jahr 2001 als verbindlicher Standard vom NIST verabschiedet und relativ schnell in den IPSec-Standard aufgenommen werden, vermutlich als zustzlicher obligatorischer Verschlsselungsalgorithmus. Damit steht ein schneller Algorithmus zur Verfgung, der als 128-Bit-Algorithmus in einer gleichen Systemumgebung schon deutlich schneller als 56Bit-DES ist. Allerdings sollte man sich zum heutigen Zeitpunkt noch nicht ausschlielich auf Rijndael sttzen, denn der Algorithmus ist einfach noch zu neu. Eine der groen Strken von DES und damit auch von Triple-DES ist die Tatsache, dass in den letzten 25 Jahren niemand eine Angriffsmethode gefunden hat, die schneller ist als ein Brute-Force-Angriff. Diesen Beweis muss Rijndael erst noch antreten. Fr dieses Verfahren gibt es erst vergleichsweise wenige Kryptoanalysen, so dass man es noch nicht sinnvoll mit Triple-DES vergleichen kann. Nicht ohne Grund hat das NIST als AES-Backup-Algorithmus den Veteranen Triple-DES ausgewhlt und keinen neuen Algorithmus.
10.7 Auswahl der VPN-Technologie

10.7.1 VPN-Typ
Die Auswahl der geeigneten VPN-Typen ist wohl der einfachste Teil beim Design eines VPN. Je nachdem in welcher Kombination Remote Access, die Verbindung von Geschftstellen und der Extranet-Zugriff eingesetzt werden, sind die entsprechenden Arten zu verwenden. Es gibt jedoch auch eine gewisse Grauzone zwischen Branch-Office- und Remote-Access-VPNs. In vielen Fllen macht es wirtschaftlich Sinn, kleinere Zweigstellen durch Whlverbindungen anzubinden, da sich ein Internetanschluss per Festverbindung aufgrund des dafr zu geringen Datenaufkommens nicht lohnt. Man benutzt also Whlverbindungen, um diese kleinen Auenstellen zeitweise mit dem Internet zu verbinden. Technisch gesehen verhalten sich diese Lokationen also wie normale Remote-Access-Benutzer, obwohl in Wirklichkeit ein kleines Netzwerk angebunden wird. Hierbei sind allerdings ein paar Aspekte von Wichtigkeit, die sich dadurch ergeben, dass nicht beide VPN-Gateways eine statische, offizielle IP-Adresse haben:
325
10 VPN-Design
Das VPN-Gateway in der Auenstelle bekommt im Regelfall vom Service Provider eine dynamische IP-Adresse zugewiesen, die sich bei jeder erneuten Einwahl ndert. Deshalb muss dieses Gateway, falls IPSec verwendet wird, unbedingt den IKE Aggressive Mode untersttzen. Feste Adressen werden nur in Ausnahmefllen, unter Umstnden gegen zustzliche Gebhren, vergeben. Die Verbindungen knnen nur von der Auenstelle aus aufgebaut werden. Eine Einwahl von den POPs der Service Provider in die Auenstelle ist nicht mglich. Die einzige Ausnahme ist, dass die Auenstelle eine feste offizielle IP-Adresse hat und die beteiligten Service Provider ein Dial-OnDemand-Routing fr die Auenstellen konfigurieren. Dies drfte aufgrund des Aufwands jedoch mit etlichen Zusatzkosten verbunden sein, die die Wirtschaftlichkeit einer solchen Lsung in Frage stellen knnen.
10.7.2
Die Auswahl der Tunneling-Protokolle richtet sich nach verschiedenen Kriterien, die sich leider manchmal gegenseitig ausschlieen oder ein partielles ReDesign des Netzwerks notwendig machen. Man muss sich nicht auf ein Protokoll festlegen, sondern kann auch mehrere Protokolle parallel benutzen und diese auch verschachteln. Bei Internet-VPNs, die eine gewisse Sicherheit auf der Netzwerkebene bedingen, gibt es keine Alternative zu IPSec oder notfalls PPTP. Das gleiche gilt auch, wenn eine PKI existiert, in Planung ist oder extern benutzt werden soll. Auch dann fhrt an IPSec kein Weg vorbei, da IPSec als einziges Protokoll eine Authentifizierung durch eine digitale Signatur ermglicht. In Tabelle 10.5 finden Sie eine bersicht ber die fr Remote-Access-VPNs interessanten Tunneling-Protokolle. Es wurden dabei nur die fr diesen Einsatzbereich wichtigen Eigenschaften bercksichtigt. Da es sich, bis auf IPSEc, um Layer-2-Tunneling-Protokolle handelt, knnen diese nur ber PPP-Whlverbindungen betrieben werden. IPSec kann als Layer-3-Tunneling-Protokoll ber alle mglichen LAN- und WAN-Infrastrukturen betrieben werden. Bei Remote-Access-VPNs kann es auch ein wichtiger Punkt sein, ob ein zwangsweises oder ein freiwilliges Tunneling eingesetzt werden soll. Da IPSec fast ausschlielich als Ende-zu-Ende-Modell eingesetzt wird, ist hier nur freiwilliges Tunneling mglich. Beim Vergleich der verschiedenen Protokolle sollte beachtet werden, dass auch Kombinationen (vgl. Kapitel 6) unterschiedlicher Tunneling-Protokolle durchaus sinnvoll sein knnen, um verschiedene Schwchen einzelner Protokolle auszugleichen.
326
Ermitteln der QoS-Parameter
IPSec Dynamische IP-Adressen LAN-Verbindungen Whlverbindungen (PPP) Wissensbasierende Authentifizierung Authentifizierung d. digitale Signatur Datenverschlsselung Paket-Authentifizierung Paket-Integrittsprfung Schutz vor Replay-Angriffen Schutz vor Denial-of-Service-Angriffen Zwangsweises Tunneling Freiwilliges Tunneling IP-Tunneling IPX-Tunneling Ja Ja Ja Ja Ja Ja Ja Ja Ja Sehr gut Nein Ja Ja Nein
PPTP Ja Ja Ja Ja Nein Ja Nein Nein Ja Nein Ja Ja Ja
L2TP Ja Nein Ja Ja Nein Nein Nein Nein Nein Ja Ja Ja Ja
L2F Ja Nein Ja Ja Nein Nein Nein Nein Nein Schwach Ja Nein Ja Ja
Schwach Mittel
Tab. 10.5: Tunneling-Protokolle fr Remote-Access-VPNs
10.8 Ermitteln der QoS-Parameter

Die VPN-Technologie muss die erforderlichen QoS-Merkmale, die die abzulsenden Technologien bieten, so weit zur Verfgung stellen, wie sie auch tatschlich bentigt werden. Falls bestimmte Applikationen, zum Beispiel Sprache oder interaktives Video, gewisse Mindestwerte unbedingt bentigen, so hat dies in die Planung mit einzuflieen. In der Regel spielen folgende Parameter und Kriterien eine Rolle, um festzulegen, welche Qualittsmerkmale eine VPN-Verbindung aufweisen muss: Minimale Bandbreite Maximale Bandbreite (Burst rate) Maximale Verzgerung (Delay) Variation der Paketverzgerung (Jitter) Fehlerrate Verfgbarkeit Admission Control IP-QoS auf Fluss- oder Klassenbasis
327
10 VPN-Design
Schnittstellen zu Layer-2-QoS (ATM-Klassen, IEEE802.q, ....) Schnittstelle zu Policy-Services Branch-Office-VPN Ein Branch-Office-VPN ersetzt oder ergnzt Festverbindungen, Frame Relay oder ATM. Nachdem in der Ist-Analyse ermittelt wurde, welches Verkehrsprofil diese Verbindungen aufweisen, und die Planungsvorgaben festlegen, fr welche neuen Anforderungen neue Applikationen und Dienste eingesetzt werden sollen, kann man daraus ein Anforderungsprofil ableiten, aufgrund dessen die geeignete VPN-Technologie und der geeignete Service Provider ausgesucht werden knnen falls dies berhaupt mglich ist und bestimmte Anforderungen den Einsatz eines Internet-VPN ausschlieen. Remote-Access-VPN Das Remote-Access-VPN lst den klassischen Remote Access ab, allerdings nur auf der Einwahlseite. Die Anwender selbst whlen sich nach wie vor ein, nun aber bei einem Service Provider und mglicherweise mit einer zustzlichen VPN-Clientsoftware. Die Qualittskriterien hierfr sind leider nicht offensichtlich. Denn eine ISDN-Verbindung ist zwar immer 64-Kbit/s schnell, hat minimale Verzgerungen und praktisch keinen Jitter, jedoch sind das keinesfalls die QoS-Merkmale, die von den Anwendungen gefordert sind. Sie sind einfach nur technologiebedingt vorhanden. In diesem Fall kann eine Ermittlung des Verkehrsprofils und der Anforderungen der Applikationen, die ber die Einwhlverbindung betrieben werden, weiterhelfen, um einen geeigneten Anforderungskatalog an die Qualitt der Dienste aufzustellen. Durch den Einsatz neuer Technologien sind viele Service Provider und Carrier mittlerweile in der Lage, ihren Remote VPN-Service um zahlreiche Dienste, unter anderem auch QoS, zu erweitern. Solche Systeme knnen aufgrund der Applikationen (Protokoll- und Portnummer) und des Benutzers die bertragenen Pakete entsprechend klassifizieren und behandeln. Eine Umsetzung dieser Serviceklassen auf z.B. ATM-Serviceklassen fr den weiteren Transport der Pakete durch den Backbone runden den Leistungsumfang solcher Systeme ab.
10.9 Die Realisierung

Da moderne Internet-VPNs fast ausschlielich IPSec einsetzen, bildet dieses Protokoll auch den Schwerpunkt in diesem Kapitel.
328
Die Realisierung
10.9.1
Routing im VPN
Wie Sie in Kapitel 7 gesehen haben, basiert IP Security auf einer Sicherheitsstrategie, der IPSec Security Policy. Diese legt genau fest, welche Adressen oder Netze ber welche Sicherheitsassoziation miteinander verbunden werden. Dies kommt allerdings einem statischen Routing gleich. Es ist aus Sicherheitsgrnden auch nicht vorgesehen, dass in IPSec Policies und SAs auf irgendeine Art gelernt werden knnen, etwa in der Art, wie es bei IP-Routing-Protokollen der Fall ist. Zudem verarbeiten gute und sichere VPN-Systeme auf ihren ffentlichen Interfaces ohnehin nur Pakete der bentigten TunnelingProtokolle und blockieren jede andere Kommunikation. Das normale Routing kann man selbstverstndlich ebenfalls nicht einsetzen, da natrlich keine privaten Netze, womglich noch mit illegalen IP-Adressen, ber das ffentliche Interface eines VPN-Gateways in das Internet eingebunden werden drfen.
Zielnetz
Netz C Netz A Netz B Netz D
Next Hop Interface Direkt GW-1 GW-1 Router-1

LAN Tunnel 1 Tunnel 1 LAN
Router 1 Netz D
Routingtabelle Gateway GW-3
VPN-Gateway GW-3
VPN-Gateway GW-1 Netz A
Internet
Tunnel 1 Tunnel 2
Netz C
VPN-Gateway GW-2 Netz B
Zielnetz
Netz A Netz B Netz C Netz D
Next Hop Interface Direkt GW-2 GW-3 GW-3

LAN Tunnel 2 Tunnel 1 Tunnel 1
Zielnetz Netz B Netz A Netz C Netz D
Next Hop Interface Direkt GW-1 GW-1 GW-1 LAN Tunnel 2 Tunnel 2 Tunnel 2
RIP-Interface IPSec-Tunnel mit RIP-Interface
Abbildung 10.1: Das VPN-Routing arbeitet nur auf privaten Schnittstellen und Tunnelendpunkten.
In groen Netzen ist dynamisches Routing aber unabdingbar, da ansonsten der Management- und Konfigurationsaufwand nicht mehr zu bewltigen ist. Man muss also in einem groen IPSec-Internet-VPN einen Kompromiss ein-
329
10 VPN-Design
gehen und eine spezielle Art von Routing einfhren. Dieses Routing, man nennt es meist VPN-Routing, darf auf gar keinen Fall eine Paketweiterleitung (Forwarding) zwischen privaten und ffentlichen Interfaces oder zwischen Tunnelendpunkten und ffentlichen Interfaces durchfhren. Das Forwarding darf nur zwischen privaten Interfaces, zwischen privaten Interfaces und Tunnelendpunkten und zwischen Tunnelendpunkten stattfinden. Das Routingprotokoll luft auch nur im Intranet und ber Tunnelverbindungen, nicht jedoch auf dem ffentlichen Interface. In Abbildung 10.1 sehen Sie, wie insgesamt vier verschiedene IP-Netze an drei Standorten ber zwei IPSec-Tunnel miteinander verbunden sind. Das Routing ist dabei nur auf den Tunnelendpunkten und den privaten Interfaces mglich. Die Routing-Updates werden nicht auf dem ffentlichen Interface ausgegeben und empfangen, sondern durch die Tunnel bertragen. Bei kleinen Netzen reicht es auch aus, statisches Routing einzusetzen. Bei greren oder stark wachsenden VPNs sollte man jedoch darauf achten, dass die VPN-Gateways das VPN-Routing auf Basis von RIP-2 oder, im Fall sehr groer Netze, auch OSPF untersttzen.
10.9.2
Remote Access
Der Remote Access ist einer der wichtigsten Sttzpfeiler heutiger VPNs, da hier das grte Ratiopotenzial liegt. Allerdings kann man hier auch sehr viele unntige Kosten erzeugen. VPN-Konzentrator Der VPN-Konzentrator ersetzt den oder die herkmmlichen Remote-AccessServer, in die sich die Remote-Benutzer per Modem oder ISDN eingewhlt haben. Um ein solches System funktionell zu ersetzen, mssen eine Reihe von Kriterien beachtet werden:
Anzahl paralleler virtueller Verbindungen Die Anzahl der parallelen Tunnel
muss mindestens der Anzahl der Benutzer entsprechen, die sich gleichzeitig einwhlen drfen. Man sollte diesen Wert aber mit Blick auf die Zukunft nicht zu niedrig ansetzen. In der Regel stellt man weniger gleichzeitige Verbindungen zur Verfgung, als man Benutzer hat; man berbucht das System. Der Grad der berbuchung ist ein Wert, der ausschlielich vom Einsatzgebiet des Remote-Access-VPN bestimmt wird. Die Bandbreiten reichen in der Praxis von einer 1:10-berbuchung bis hin zur Garantie einer Verbindung. Es gibt nmlich durchaus VPN-Einsatzgebiete, die eine berbuchung verbieten, z.B. Online-Reservierungssysteme in Reisebros, Online-Vertragsabschlsse usw. Hier erfordert das Geschftsmodell, dass immer eine Verbindung zustande kommen muss.
330
Die Realisierung
Gesamtdurchsatz Der Gesamtdurchsatz ist ein sehr interessanter Faktor, der zunehmend an Bedeutung gewinnt. Zunehmend deshalb, weil er in Zukunft sehr viel hher sein muss als der eines vergleichbaren Remote-Access-Konzentrators. Der Grund liegt darin, dass zunehmend mit hheren Geschwindigkeiten als den 56 Kbit/s eines Modems oder 64 kBit/s von ISDN gearbeitet wird. Die DSL-Technologie ermglicht Datenraten von mehreren hundert Kilobit. Ein Remote-Access-Server fr 600 Benutzer bentigt im schlimmsten Fall einen Durchsatz von 600 x 64 Kbit/s = 34 Mbit/s, ein Wert, der technisch kein Problem darstellt. Im VPN-Konzentrator she der schlimmste Fall jedoch so aus, dass alle Benutzer DSL einsetzen und ingesamt 600 x 768 Kbit/s = 460 Mbit/s an Bandbreite bentigen. Dies ist natrlich nur ein theoretischer Fall. Bleiben wir auf dem Teppich und nehmen wir an, dass nur 10% der Benutzer DSL einsetzen und der Rest ISDN. Angenommen, es wrden dabei nur 10% der Bandbreite benutzt, dann betrge die erforderliche Bandbreite in diesem Beispiel immer noch 8 Mbit/s.
Falls jedoch die Remote-Access-Systeme aus wirtschaftlichen Grnden stark berbucht sind, also fr 3000 mgliche Benutzer nur 600 Ports oder Tunnel zur Verfgung stehen, dann muss man davon ausgehen, dass in den Stozeiten alle 600 Verbindungen gleichzeitig benutzt werden. Der bentigte Durchsatz in diesem Beispiel wrde dann auch in hhere Regionen vorstoen. Etwa 30 Mbit/s sind dabei als durchaus realistischer Wert anzusehen. Bei den berlegungen zum Durchsatz sei an dieser Stelle darauf hingewiesen, dass es sich bei einem Internet-VPN dabei natrlich um den Systemdurchsatz mit starker Verschlsselung (>128 Bit) und IPSec-Komprimierung handeln muss und nicht um einfaches Paketweiterleiten.
Anbindung an den Service Provider Die Art der Verbindung zum Service Provider richtet sich nach verschiedenen Gegebenheiten. Zum einen ist es der bentigte Gesamtdurchsatz, denn die Verbindung zum ISP muss sinnvollerweise mindestens die gleiche Bandbreite aufweisen; auf der anderen Seite flieen bestimmte, geforderte Qualittskriterien mit ein.
Aus der Bandbreite und etwaigen Vereinbarungen in einem Service Level Agreement leiten sich dann meist die eingesetzte Technologie und die Geschwindigkeit ab.
Untersttzte Authentifizierungssysteme Je nach geplantem Soll-Zustand
und den durch die Migrationsphase bedingten Anforderungen an einen zeitweisen Parallelbetrieb mssen unter Umstnden verschiedene BenutzerAuthentifizierungssysteme untersttzt werden. Praktisch alle ernsthaften Remote-Access-Server arbeiten mit RADIUS. Moderne VPN-Remote-AccessKonzentratoren unterstzten neben RADIUS auch noch andere Verfahren; insbesondere wird zunehmend LDAP-Support angeboten.
331
10 VPN-Design
Falls die Remote-Access-Benutzer bereits Token-Karten zur Authentifizierung benutzen, muss dieses Verfahren ebenfalls untersttzt werden knnen. Der Idealzustand ist der, dass die Anwender ihre bisherigen User-IDs, Passwrter und Token-Karten weiter benutzen knnen.
IP-Adressmanagement Beim Remote Access ist es blich, dass die Rechner der
Benutzer whrend des Verbindungsaufbaus zum Einwhlsystem von diesem eine fr die Zeit der Verbindung gltige IP-Adresse zugewiesen bekommen. blicherweise erfolgt die Zuweisung ber das PPP-Protokoll, das alle heutigen Einwhlprogramme, z.B. das Microsoft DF-Netzwerk, untersttzen. In diesem Fall bekommt der Remote-Access-Konzentrator, wie Sie in Abbildung 10.2 sehen, bei einer erfolgreichen Authentifizierung vom RADIUS-Server eine IPAdresse geliefert, die er ber IPCP (IP Configuration Protocol, vgl. Kapitel 9) dem Remote-Rechner fr die Dauer der Verbindung zuweist.
RemoteAccess-Client
Remote-AccessKonzentrator
RADIUSServer
ISDN PSTN
PPP-LCP und PPP-Authentifizierung
BenutzerIP-Adresse
PPP-NCP (IPCP-Konfiguration)
Abbildung 10.2: IP-Adressvergabe beim Remote Access (PPP)
Im Fall von IPSec liegt der Fall jedoch anders, wie Sie in Abbildung 10.3 sehen. Hier besteht ja bereits eine PPP-Whlverbindung zum Service Provider, und der Rechner des Anwenders hat von diesem bereits eine offizielle IPAdresse zugewiesen bekommen. IPSec (im Tunnelmodus) bentigt aber noch eine zustzliche private IP-Adresse, die in der Regel ber entsprechende Informationsnachrichten des IKE-Protokolls an den IPSec-Client bertragen wird. Diese IP-Adresse entspricht der IP-Adresse, die bisher vom RemoteAccess-Server zugewiesen wurde. Hierfr mssen, je nach Planung, die gleichen Mechanismen untersttzt werden knnen, die auch ein Remote-AccessServer bietet. Die IP-Adressen knnen im Allgemeinen aus folgenden Quellen stammen: Interner IP-Adress-Pool im VPN-Konzentrator IP-Adressvergabe pro Benutzer im VPN-Konzentrator IP-Adressvergabe von einem RADIUS-Server, hier auch per User oder aus einem Pool
332
Die Realisierung
Service Provider RADIUS-Server
Kunden RADIUS-Server
RemoteAccess-Client
POP
ISDN PSTN
Internet
IPSecGateway
IPSec- DFClient Client
PPP-LCP und PPP-Auth

PPP-NCP (IPCP-Konfig.)
BenutzerIP-Adresse
IP-Verbindung
IKE Phase 1
IKE-Konfig (Virtuelle IP-Adresse zuweisen)
IKE Phase 2 IPSec-ESP/AH-SA
IKE-Auth IP-Adr.
Abbildung 10.3: Das IKE-Protokoll kann zur Zuweisung einer privaten IP-Adresse benutzt werden.
Optional sollten noch folgende Verfahren untersttzt werden, die in modernen und zukunftssicheren Netzen immer wichtiger werden: IP-Adressvergabe von einem DHCP-Server IP-Adressvergabe von einem LDAP-Verzeichnisdienst per User, per Gruppe oder aus einem Pool
Accounting und Logging Da der Remote Access je nach Ausbaustufe ein
betrchtlicher Kostenfaktor ist, gibt es schon seit lngerem entsprechende Accounting-Funktionen. Mit den damit aufgezeichneten Daten ist es mglich, die Leistungen und daraus resultierenden Kosten bis auf Benutzerebene auszuweisen. blicherweise benutzt man dafr auch RADIUS. Ein brauchbarer VPNKonzentrator erzeugt ebenfalls RADIUS-Accounting-Datenstze und schickt diese zum RADIUS-Accounting-Server. Damit kann man seinen virtuellen Remote Access reibungslos in das bestehende Abrechnungssystem integrieren. Da Remote Access, genau wie ein VPN auch, ffentliche Netze benutzt, wurde in vielen Installationen bereits reger Gebrauch von den Logging-Funktionen gemacht. Logging dient im Gegensatz zum Accounting weniger zu Abrechnungszwecken als zur Kontrolle eines ordnungsgemen und vor
333
10 VPN-Design
allem sicheren Betriebs von Remote-Access-Konzentratoren. Beim Logging kann man sowohl kritische Systemzustnde als auch mgliche Angriffe erkennen und darauf reagieren. Gute Logging-Implementierungen erlauben es, verschiedene Logs zu fhren, entsprechend der Art der Daten, die gesammelt werden sollen: Security Log fr alle sicherheitsrelevanten Ereignisse Configuration Log fr alle Konfigurationsnderungen System Log fr System- und Gerte-Informationen Viele spezielle VPN- oder Security-Gateways haben einen einfachen, aber wirkungsvollen Schutz gegen eine bestimmte Art von Denial-of-ServiceAngriffen (DoS) eingebaut. Falls man nmlich zu viele Logging-Informationen sammelt, bietet man damit leider auch ein hervorragendes Angriffsziel. Dies wird an einem kleinen Beispiel schnell deutlich: Wenn ein IPSec-System alle abgewiesenen und nicht bearbeiteten (Silent-discard-)Pakete aufzeichnet, dann erfordert dies einen gewissen Aufwand durch die interne Aufzeichnung und das Schreiben auf einen externen Server. Wenn nun ein Angreifer eine Reihe von kleinsten Paketen, die in jedem Fall abgewiesen werden, auf ein VPN-Gateway schickt, dann kann er, ohne groe Netzlast auf dem ffentlichen Interface zu erzeugen, das Gateway dazu bringen, nichts mehr zu tun, als Logging-Eintrge zu verarbeiten. Also sollte man sein System sorgfltig konfigurieren und dafr Sorge tragen, dass nur wichtige Ereignisse aufgezeichnet werden.
Sicherheit Die Sicherheit eines VPN-Remote-Access-Konzentrators kann
man in zwei Teilbereiche untergliedern: die Sicherheit der eingesetzten Tunneling-Protokolle und die Sicherheit des Systems selbst. Echte Sicherheit bieten praktisch nur zwei Tunneling-Protokolle, IPSec und PPTP. Letzteres ist allerdings schon mehrfach Zielscheibe von Angriffen geworden (vgl. Kapitel 6) und bietet auch bei weitem nicht so viele Sicherheitsmechanismen wie die IP-Security-Protokollfamilie. Die Systemsicherheit selbst ist uerst kritisch. Das wird leider in vielen Fllen vllig unterschtzt. Versetzen wir uns einmal kurz in einen Angreifer, der auf bestimmte Netzressourcen eines Unternehmens illegal zugreifen will. Er wird, um sich selbst zu schtzen, mglichst versuchen, nicht physisch in das Unternehmen selbst einzudingen, sondern dies ber Remote Access oder das Internet zu tun. Wenn er nun feststellt, dass das Unternehmen in seinem VPN durchgehend IPSec, unter Umstnden sogar noch mit starker Verschlsselung (z.B. Triple-DES), einsetzt, dann wird er es an dieser Stelle erst gar nicht versuchen. Er sucht sich dann einen anderen Schwachpunkt im Netzwerk, und dieser kann im Zugriff auf die IPSec-Gateways liegen, falls hiergegen keine Manahmen getroffen werden. Hier gibt es ein paar Dinge, die man unbedingt beachten sollte:
334
Die Realisierung
Kein direkter Out-of-Band-Zugriff: Falls man das Gert ber Modem- oder ISDN-Verbindungen fernwarten mchte, ffnet man damit die klassische Hintertr. Wenn man unbedingt einen Out-of-Band-Zugriff bentigt, dann muss dieser verschlsselt (SSL, IPSec) erfolgen und stark authentifiziert werden. Der lokale Zugriff auf ein VPN-Gateway sollte in jedem Fall verschlsselt erfolgen, entweder ber SSL oder noch besser gleich ber IPSec. Denken Sie daran: Mehr als 80% aller Angriffe auf Rechner und Netzwerke erfolgen innerhalb eines Unternehmens und nicht von auen. Die Systeme mssen ihrer Sicherheitseinstufung entsprechend in durch bauliche Manahmen sicheren Umgebungen mit einer geeigneten Zugangskontrolle betrieben werden.
Administration Beim Thema Administration scheiden sich oft die Geister,
denn hier treffen praktisch zwei Weltanschauungen aufeinander: die textbasierende und die grafische Administration. Hier objektiv zu urteilen ist unmglich, da beide Varianten sowohl Vor- als auch Nachteile aufweisen und auch sehr stark von persnlichen Vorlieben der Administratoren selbst geprgt sind. In der Praxis ist es natrlich eine geschickte Lsung, wenn ein VPN-System beide Varianten untersttzt und der Administrator das auswhlt, was es ihm erlaubt, seine Ttigkeit am effizientesten auszuben. Heute blich sind grafische Oberflchen auf Basis von Webbrowsern, da hiermit praktisch von jedem Rechner aus auf das VPN-System zugegriffen werden kann. Aber sowohl die grafische als auch die textbasierende Administration kann gut oder schlecht implementiert werden und im letzten Fall erhhte Personalkosten, oder schlimmer noch, auch Sicherheitsprobleme nach sich ziehen. Hier sollte man auf bersichtlichkeit, Einfachheit und Konsistenz achten der Administrator sollte genau wissen, was er tut und was seine nderungen an der Konfiguration tatschlich bewirken.
Integration in PKI und Verzeichnisdienste Moderne und zukunftssichere Netze setzen zum Teil schon Verzeichnisdienste oder PKIs (Public Key Infrastructure) ein oder planen zumindest, dies in der Zukunft zu tun. Fr die Realisierung eines VPN bedeutet dies, dass es die entsprechenden Schnittstellen zu solchen Systemen bereits untersttzen muss.
Im Bereich der Verzeichnisdienste gab es in der Vergangenheit viele herstellereigene Anstze, die sich aber letztendlich nicht durchsetzen konnten. Beispiele hierfr sind StreetTalk von Banyan und NDS von Novell. Auch Standards, wie z.B. X.500, hielten nur wenig Einzug in praktische Implementierungen, da sie nicht selten etwas berdimensioniert erschienen. Auch LDAP (Lightweight Directory Access Protocol) fristete lange ein Schattendasein, wird aber immer mehr zu dem Standardprotokoll fr Verzeichnisdienste. Dies liegt an der
335
10 VPN-Design
zunehmenden Untersttzung durch Hersteller von Betriebssystemen und Netzwerkkomponenten. Sun/Netscape, Microsoft und Novell setzen immer mehr auf dieses Protokoll, und viele Netzwerkdienste wie Policy Services oder die Verwaltung von Systemprofilen basieren auf LDAP. Im Bereich der PKIs setzen sich erst langsam die Standards der IETF durch, dadurch haben die verschiedenen Hersteller lange Zeit ihr eigenen, zu anderen Produkten inkompatiblen Systeme entwickeln knnen. Es gibt zwar eine Reihe von Standards, zum Beispiel X.509 fr das Format von digitalen Zertifikaten, aber die Verteilung und das Management erfolgen meist noch mit proprietren Produkten und Protokollen. Hier muss man sowohl darauf achten, dass die Standards untersttzt werden, als auch auf die im Unternehmen eingesetzten oder noch einzusetzenden Produkte. VPN-Clients Um es vorweg zu nehmen: In einem Remote-Access-VPN entscheidet zu einem mageblichen Teil der VPN-Client darber, ob das VPN Kosten letztendlich einspart oder viel mehr Kosten erzeugt oder ob es berhaupt in groem Mastab einsetzbar ist. Das Einsparen von Kosten wurde bereits besprochen. Wodurch kann ein VPN-Client hohe Kosten erzeugen? Ganz einfach: Je grer ein Remote-Access-Einsatz ist, desto mehr Anwender benutzen den VPN-Client und desto mehr multiplizieren sich auch die Probleme, die es damit eventuell gibt. Wenn 100 Clients produktiv eingesetzt werden und ein Problem erzeugen, das eine Hotline pro Woche 30 Stunden kostet und einen Ausfall der Arbeit mit den Clients von 50 Stunden zur Folge hat, dann sind es bei 1000 Systemen schon 300 Stunden Hotline und 500 Stunden Arbeitsausfall. Worauf muss man bei VPN- oder speziell auch IPSec-Clients besonders achten? Die folgende Aufzhlung deckt die wichtigsten Punkte ab, die im Folgenden noch ausfhrlich besprochen werden: Einfache Installation ohne Eingaben des Benutzers Keine weitere Konfiguration durch den Benutzer notwendig Keine Konfigurationsnderung durch den Benutzer mglich Zentrale Verwaltung und Konfiguration Split-Tunneling darf nicht durch den Anwender konfigurierbar sein Integrierte Untersttzung fr Token-Authentifizierung Integrierte Untersttzung fr Authentifizierung mit digitalen Signaturen Benutzertransparentes Zertifikat-Management Automatischer Backup/Failover-Mechanismus API oder direkter Aufruf per Kommandozeile oder System-Call
336
Die Realisierung
Die Installation des VPN-Clients kann bereits schon viele Kosten sparen, und zwar dann, wenn der Benutzer dies selbst tun kann und nicht aus diesem Grund zum Benutzerservice muss. Somit sparen sowohl der Benutzer als auch die PC-Administration wertvolle Zeit. Ein gute Installation luft ohne Abfrage von Parametern durch und kann an die Gegebenheiten eines Unternehmens angepasst werden (Customizing). Der Benutzer braucht im Idealfall gar nichts zu konfigurieren; die Installation ist damit praktisch von jedem durchzufhren, der bereits einen PC benutzt. Clientimplementierungen, bei denen Anwender irgendwelche Systemdateien manuell editieren mssen oder bei denen Parameter abgefragt werden (Beispiel: Wollen Sie Perfect Forwarding Secrecy [Ja/Nein]?), mit denen ein Anwender nichts anfangen kann, sollten von vornherein nicht in Betracht gezogen werden. Damit kommen wir auch zum nchsten Punkt, denn bei einer guten VPN-Clientsoftware braucht der Anwender nicht nur nichts zu konfigurieren, sondern er darf es berhaupt nicht knnen. Denn es ist der Horror eines jeden Sicherheitsverantwortlichen, wenn die Endanwender in der Lage sind, auf ihren IPSec-Clients irgendwelche Konfigurationsnderungen vorzunehmen zum Beispiel zum Zweck der Performancesteigerung die Verschlsselung abzuschalten. Es gibt zwar die Mglichkeit, dies im VPN-Remote-Access-Konzentrator zu unterbinden und berhaupt keine IPSec-Sicherheitsassoziation aufzubauen, aber dann existiert wieder der Fall, dass vom Benutzer ein Anruf (Mein Rechner tuts nicht mehr) im Help Desk erfolgt. Aber auch andere, nicht sicherheitsrelevante nderungen, die ein Anwender vielleicht mit den besten Absichten vornimmt knnen Probleme und Kosten nach sich ziehen. Idealerweise werden die VPN-Clients zentral konfiguriert, entweder auf dem Remote-Access-VPN-Konzentrator selbst oder auf einem Directory-Server. Die aktuelle Konfiguration wird dann bei jedem Verbindungsaufbau auf den VPNClient heruntergeladen. Neben der Sicherheit und dem Fehlen der Mglichkeit einer falschen Konfiguration durch den Benutzer ist damit auch eine sehr effiziente Mglichkeit der Administration gegeben, und alle nderungen sind absolut zeitnah. nderungen fr mglicherweise mehrere Tausend VPN-Clients werden nur einmal vorgenommen, und jeder Client bekommt sein Update beim nchsten Einwhlen einfacher und effizienter geht es kaum noch.
IPSec-Client mit Spit-Tunneling
tftp p, htt
IPSec-Tunnel
IPSec-RemoteAccess-Konzentrator
Internet
Abbildung 10.4: Split-Tunneling kann eine Sicherheitslcke erzeugen.
337
10 VPN-Design
Ein Sache, die auf gar keinen Fall durch den Anwender beeinflussbar sein darf, ist das so genannte Split-Tunneling. Split-Tunneling bedeutet, wie Sie in Abbildung 10.4 sehen knnen, dass sowohl ein sicherer IPSec-Tunnel in das Unternehmensnetz existiert als auch parallel dazu Datenverkehr mit anderen Gegenstellen, z.B. im Internet, mglich ist ein fatales Sicherheitsloch, denn damit ffnet man das Unternehmensnetz dem Internet. Das mchte man natrlich nicht, also ist Split-Tunneling in aller Regel unerwnscht, und eine gute Clientimplementierung sorgt dafr, dass, sobald sie aktiv ist, Datenverkehr nur noch durch den Tunnel mglich ist. Von dieser Regel gibt es allerdings zwei Ausnahmen, in denen es sinnvoll ist, sowohl durch einen Tunnel als auch mit anderen Systemen zu kommunizieren. Die eine ist ein virtuelles lokales Netzwerk auf IP-Ebene, in dem verschiedene Systeme ber IPSec miteinander kommunizieren und andere Systeme nicht. Die andere Ausnahme, die Sie in Abbildung 10.5 sehen, sind kleine Heim- oder Zweigbros, in denen ein oder mehrere Rechner mit IPSec-Clients sowohl mit dem Unternehmensnetz als auch lokal kommunizieren mssen, zum Beispiel um Daten des zentralen SAP-Systems, mit dem sie ber einen IPSec-Tunnel kommunizieren, lokal auf einem Netzwerkdrucker auszugeben.
IPSecClient
10.1.1.0/24
Router
IPSecGateway
IPSec-Tunnel
Internet
Netzwerkdrucker
Abbildung 10.5: Hier ist sorgfltig konfiguriertes Split-Tunneling sinnvoll.
Gute VPN-Systeme, Konzentratoren und die dazugehrigen Clients, bieten die Mglichkeit, dass der Administrator zentral eine Liste von Netzwerken, Rechneradressen oder Domainnamen pflegt, mit denen bei freigegebenem Split-Tunneling kommuniziert werden darf. In dem Beispiel in Abbildung 10.5 wrde der Administrator Split-Tunneling freigeben und als zulssigen IP-Adressbereich das lokale Klasse-C-Netzwerk 10.1.1.0 eintragen, in dem sich der PC befindet. Somit kann keine Kommunikation am IPSec-Tunnel vorbei mit dem Internet stattfinden, innerhalb des lokalen Netzwerks knnen die Systeme jedoch bei einem aktiven Tunnel miteinander kommunizieren. Die verschiedenen Authentifizierungssysteme sollten im Sinne einer guten Handhabbarkeit durch den Benutzer von der Clientsoftware untersttzt werden. So sollten zum Beispiel bei einer Authentifizierung, beispielsweise mit
338
Die Realisierung
SecurID-Token-Karten, statt eines Passwort-Feldes die beiden Felder fr PIN und Token angezeigt werden. Spezielle Funktionen, wie wenn wir beim Beispiel SecurID bleiben Next-Token-Modus oder New-PIN-Modus, sollten ebenfalls von der VPN-Clientsoftware erkannt und aktiv untersttzt werden knnen. Das Gleiche gilt auch fr den Umgang mit digitalen Zertifikaten, falls eine Authentifizierung mit digitalen Signaturen eingesetzt werden soll. Das ganze Zertifikat-Management, inklusive der Erzeugung der asymmetrischen Schlssel und der Certificate-Requests, sollte so weit wie nur irgendwie mglich vom Endanwender abgeschirmt werden knnen. Es ist einem normalen Anwender, also keinem PC- und Sicherheitsexperten, nicht unbedingt zumutbar, manuelle Zertifikat-Anforderungen zu erzeugen und diese mit Cut-and-Paste per Datei oder E-Mails an eine CA zu bertragen oder erhaltene Zertifikate manuell zu importieren. Leider muss ich an dieser Stelle sagen, dass die Technologie, die heute in Form verfgbarer Produkte vorliegt, dem nur unzureichend Rechnung trgt. Insbesondere die Implementierung der Internetstandards der IETF zum Thema PKIX (Public Key Infrastructure X.509) lsst bei etlichen Herstellern sehr zu wnschen brig, und zwar sowohl bei den Herstellern der VPN-Systeme als auch bei Herstellern von PKI-Software. Und hier mssen beide Seiten mitspielen. Ganz trbe sieht es dann bei der Untersttzung von Chipkarten aus, da werden im Augenblick leider fast nur proprietre Lsungen angeboten. Das ist umso schlimmer, als dies die einzige sichere und vernnftige Art des Umgangs mit digitalen Signatur-Zertifikaten ist. Falls der Remote Access ber ein VPN eine geschftskritische Stellung einnimmt, dann sind hier natrlich Manahmen zur Ausfallsicherheit erforderlich. Das Ganze sollte natrlich weitgehend automatisch erfolgen, der Benutzer sollte weder irgendwelche Konfigurationen vornehmen mssen noch manuell ein Backup-System anwhlen mssen. Auch hier sollte eine zentrale Konfiguration erfolgen, und die VPN-Clients lernen ihre Backup-Systeme bereits beim Verbindungsaufbau. Natrlich muss auch die letzte Einstellung gespeichert werden, denn wenn das primre System nicht verfgbar ist, muss ein Ausweichsystem bekannt sein. Um eine automatische Zuweisung von Backup-Systemen beim Verbindungsaufbau kommt man berhaupt nicht herum, wenn die zentralen VPN-Konzentratoren eine automatische Lastverteilung (Loadbalancing) untereinander durchfhren. Denn dann wei man ja nie im Voraus, auf welchem VPN-Konzentrator die aktuelle IPSec-SA gerade terminiert wird, und kann somit auch keine statischen Backup-Adressen verwenden. Einige, vor allem grere Unternehmen haben spezielle, teilweise eigenentwickelte Oberflchen fr den Remote Access ihrer Mitarbeiter. Diese Applikationen pflegen Einwhlverzeichnisse, Sicherheits- und Systemeinstellungen
339
10 VPN-Design
und bieten dem Anwender eine einfache, einheitliche und komfortable Anwenderoberflche. Systemdienste, wie zum Beispiel das Microsoft-DFNetzwerk, werden von dieser Applikation automatisch gestartet, ohne dass der Anwender etwas dazu tun muss. Wenn nun zustzlich zum Einwhldienst noch ein VPN-Client hinzukommt, muss dieser ebenso von der Applikation gestartet werden knnen. Entweder bietet der Client dafr ein API (Application Programming Interface), also eine Programmierschnittstelle, oder er sollte wenigstens durch einen Kommandozeilenaufruf oder einen Systemaufruf gestartet und mit entsprechenden Parametern, z.B. Zieladresse, User-ID, PIN und Token, versorgt werden knnen, um dann mglichst im Hintergrund abzulaufen. Client-Rollout und Updates Der Rollout der VPN-Clients ist auch eine heikle Angelegenheit, die entweder sehr einfach oder sehr aufwendig und damit sehr teuer werden kann. Gute Clients sind vom Endbenutzer ohne Spezialkenntnisse zu installieren. Sie bieten die Mglichkeit, dass das Unternehmen, das die Clients einsetzt, diese auch bestimmten Gegebenheiten anpassen kann. Insbesondere Zielverzeichnisse, Zieladressen von VPN-Gateways und andere Konfigurationsparameter, die von Unternehmen zu Unternehmen unterschiedlich sind, sollten in einer entsprechenden Konfigurationsdatei den Installationsvorgang steuern. Die Softwareverteilung kann man sich dann auch sehr einfach machen, indem man den Client auf einen ffentlichen Server legt oder per Datentrger an die Anwender verteilt. Ein Umstieg eines Remote-Access-Benutzers, der Token-Karten zur Authentifizierung benutzt, auf die VPN-Technologie kann bei einem gut geplanten Rollout und einer geeigneten Konfigurationsdatei etwa so aussehen, wie Sie es in Abbildung 10.6 sehen knnen: 1. Der Remote-Access-Anwender greift per Einwahl auf das Unternehmensnetz zu und ldt sich von einem Webserver das Installationsimage des VPN-Clients herunter. 2. Anschlieend startet er die Installation, und der IPSec-Client wird auf seinem Rechner installiert und konfiguriert. Als Teil der Installationsroutine kann optional die Erzeugung eines neuen Eintrags fr das Microsoft DFNetzwerk erfolgen, um sich damit zu einem Internet Service Provider zu verbinden. 3. Der Anwender startet seinen IPSec-Client, der seinerseits das Microsoft DF-Netzwerk startet und eine Verbindung zum ISP aufbaut, gibt seine User-ID, seine PIN und sein Token ein und kann sich damit sofort am IPSec-VPN-Konzentrator authentifizieren, da dieser, ebenso wie der Remote-Access-Konzentrator auch, mit dem Token-Server kommuniziert.
340
Die Realisierung
Man sieht, dass der Rollout, auch von Tausenden von Clients, relativ schnell und effizient vonstatten gehen kann, vorausgesetzt, die VPN-Clientsoftware ist dementsprechend ausgelegt.
Zentrale
RemoteAccessKonzentrator
RemoteClient
ISDN PSTN
1. VPN-Clientimage herunterladen
Webserver mit dem Installationsimage des VPN-Clients
VPNKonzentrator
2. VPN-Client installieren
TokenServer
Internet
3. VPN-Zugriff
Abbildung 10.6: Online-Verteilung der VPN-Clientsoftware
10.9.3
Kleine Auenstellen und Heimbros
Im Fall von sehr kleinen Auenstellen oder Heimarbeitspltzen, die man kurz unter dem Oberbegriff SOHO (Small Office Home Office) zusammenfasst, steht man oft vor dem Problem, dass sich aufgrund des geringen Datenaufkommens keine Festverbindungen oder in unserem Fall keine BranchOffice-VPN-Modelle rentieren. Man weicht daher auf Whlverbindungen aus, die bei richtigem Einsatz nur dann Kosten erzeugen, wenn auch wirklich Daten bertragen werden. blicherweise benutzt man dafr heutzutage spezielle ISDN-Router, die sich in normale Remote-Access-Konzentratoren einwhlen. Dabei gilt es, vor allem im Hinblick auf den VPN-Einsatz, zwei grundstzlich verschiedene Einsatzszenarien zu unterscheiden: Der ISDN-Router verhlt sich gegenber dem Remote-Access-Konzentrator genau wie ein normaler Benutzer und bekommt insbesondere auch eine dynamische IP-Adresse zugewiesen. Der Router versteckt das kleine SOHO-Netzwerk, indem er One-to-Many-NAT einsetzt. Diese Form von NAT (Network Address Translation) setzt dynamisch eine IPAdresse auf mehrere private Adressen um. Hierbei knnen Verbindungen nur aus dem SOHO-Netz heraus aufgebaut werden.
341
10 VPN-Design
Der ISDN-Router verhlt sich wie ein normaler Router. Er hat eine statische IP-Adresse, und sein lokales SOHO-Netz kann mittels Routing-Updates im Unternehmensnetz verteilt werden. In vielen Fllen wird der RemoteAccess-Konzentrator auch fr so genanntes Dial-On-Demand-Routing konfiguriert, er kann also auch eine Verbindung zum ISDN-Router aufbauen. Der erste Fall bereitet mit einem geeigneten IPSec-Gateway keine nennenswerten Probleme. Hier gibt es Systeme, die mit entsprechend starker Sicherheit (z.B. IPSec-ESP mit Triple-DES und SHA-1) ausgestattet sind und durch den IKE Aggressive Mode auch von einem Service Provider bei der Einwahl eine dynamische IP-Adresse zugewiesen bekommen knnen. Spezielle NATImplementierungen oder die Verwendung virtueller IPSec-Interfaces ersetzen auch die One-to-Many-NAT-Funktionalitt normaler ISDN-Router, die mit IPSec nicht kompatibel ist. Im zweiten Fall wird es allerdings problematisch, wenn die Funktionalitt vollstndig bernommen werden muss. Denn hier muss der Service Provider eine Menge Dinge tun, die er sonst nicht tut und vor allem auch berhaupt nicht mag: 1. Er muss statische IP-Adressen fr jedes System reservieren. 2. Er muss seine POPs fr Dial-Out konfigurieren. 3. Er muss auf irgendeine Art das Dial-On-Demand-Routing mit den privaten Netzen des Kunden nachbilden. 4. Weiterhin muss das VPN-Gateway des Kunden bereits eine Art virtuelles Dial-On-Demand-Routing durchfhren. Das sind alles relativ ernste Probleme. Die beiden ersten Punkte sind technisch kein Problem, es drfte nur einiges kosten. Die beiden letzten Punkte sind allerdings ernster. Hier sind einige technische Klimmzge notwendig, denn saubere Lsungen gibt es hierfr noch nicht. Es kann sich sogar herausstellen, dass hier ein Branch-Office-Modell die billigere und einfachere Alternative ist. Bei Heimbros ist das allerdings eher zweifelhaft, hier wird man eher seine Infrastruktur etwas umstellen. Oder es ist tatschlich der Fall eingetreten, in dem es weder technisch noch wirtschaftlich Sinn macht, die VPN-Technologie einzusetzen, und man weiter ISDN-Dial-In verwenden sollte.
10.9.4
Skalierbarkeit
Die Skalierbarkeit ist ein weiterer wichtiger Faktor, da es wichtig ist, die Gre der Systeme, also den Durchsatz und die Anzahl gleichzeitiger Verbindungen, entsprechend den jeweiligen Gegebenheiten anpassen zu knnen. Es mssen verschiedene Arten von Anwendungen und Standorten versorgt werden knnen:
342
Die Realisierung
Einsatzbereich Remote Access Client Heimbro Kleine Auenstelle Mittlere Niederlassung
Gert Clientsoftware Gateway Gateway
Anzahl Tunnel 1 1-5 >10 10-100 1000+
Durchsatz 56 Kbit/s bis 1 Mbit/s (DSL) 64 Kbit/s bis 1 Mbit/s 64 Kbit/s 2 Mbit/s 2 bis 10 Mbit/s 2 bis 34 Mbit/s 34 bis 70 Mbit/s
Client, Gateway 1-5
Groe Niederlassung, Zen- Gateway trale Remote-Access-Konzentrator Gateway
Tab. 10.6: Eine bersicht ber in verschiedenen Einsatzbereichen gebruchliche VPN-Systeme
In Tabelle 10.6 sehen Sie eine bersicht ber verschieden groe VPN-Systeme, abhngig von deren Einsatzbereich. Die Anzahl der Tunnel und der Durchsatz knnen natrlich je nach Einsatz und Infrastruktur stark schwanken. Die VPN-Remote-Access-Clients knnen natrlich auch in ganz kleinen Heimbros eingesetzt werden, vor allem wenn dort nur ein Rechner verwendet wird und die Peripherie direkt am PC angeschlossen ist. Auch die 1000 Tunnel beim Remote Access sind nur ein grober Anhaltspunkt, denn beispielsweise bentigt ein Unternehmen mit nur 500 Mitarbeitern keine 1000 virtuellen Einwhlports.
10.9.5
Redundanz und Ausfallsicherheit
Redundanz und Ausfallsicherheit sind Anforderungen, die aus keinem Netzwerk mehr wegzudenken sind. Entsprechend muss auch ein VPN ausgelegt werden, will man keinen Rckschritt machen. Hier setzt man am besten auf altbewhrte Methoden und verwendet entweder Systeme, die redundant ausgelegt sind, oder man schafft Redundanz durch mehrere Gerte. Zwei Gerte allein schaffen allerdings noch keine Redundanz, es mssen auch Methoden existieren, um zwischen den beiden Systemen umzuschalten, oder im Netzwerk selbst muss eine entsprechende Intelligenz implementiert sein, die dies im Bedarfsfall tut. Der erste Fall, nmlich entsprechend ausgelegte Systeme mit passiver Backplane und doppelter Auslegung aller Module und Stromversorgungen, ist in aller Regel eine sehr teure Angelegenheit und hat obendrein noch ein immanentes Problem: Dadurch, dass alles in einem Chassis konzentriert ist, kann ein massiver physischer Schaden trotzdem das komplette System lahm legen. Die zweite Lsung, zwei identische Systeme einzusetzen und diese am besten rumlich getrennt zu betreiben vielleicht noch mit zwei verschiedenen Zuleitungen zu unterschiedlichen POPs, ist eine andere, meist gnstigere
343
10 VPN-Design
Lsung. Hierfr gibt es auch einige standardisierte Verfahren, die zwei Gerte zu einem redundanten System vereinigen knnen. Das VRRP (Virtual Router Redundancy Protocol) zum Beispiel wre solch ein Verfahren. Hierbei ist ein System der VRRP-Master, und sobald dieser ausfllt, bernimmt das zweite Gert dessen Funktion und auch dessen Netzwerkadressen. Eine andere Art von Backup bzw. Redundanz ist beim Remote-Access-VPN ntig, da hier noch andere Netze (ISDN, Internet) zwischengeschaltet sind und solche Lsungen (wie VRRP) hier nicht zum Einsatz kommen knnen. Hier muss zwischen dem IPSec-Client und dem VPN-Gateway ein spezielles Protokoll den Zustand der Verbindung berwachen. Dies ist notwendig, da IPSec ein verbindungsloses Protokoll ist. Da zwischen dem Client und dem Gateway viele Vermittlungssysteme liegen knnen, knnen weder der Client noch das Gateway erkennen, dass irgendwo dazwischen ein Knoten ausgefallen ist auer sie versuchen gerade, Daten zu bertragen. Durch dieses spezielle Protokoll, das stndig so genannte Keep-Alive-Pakete bertrgt, kann eine Seite erkennen, dass die Gegenstelle nicht mehr erreichbar ist, auch wenn gerade keine Nutzdaten bertragen werden.
10.9.6
Durchsatz und Quality-of-Service
Bandbreite und Leistung Die VPN-Gateways mssen an die bentigte oder zu erwartende Last angepasst sein. Insbesondere im Fall von IPSec und starker Verschlsselung bentigt man schon einiges an Systemleistung. Als Faustregel kann man sagen, dass der Systemdurchsatz mindestens so gro sein muss wie die Zugangsleitungen. Wenn also eine Anbindung mit einer E3-Schnittstelle zu einem ISP erfolgt und dieser Durchsatz auch vertraglich garantiert wurde, dann sollte dieses IPSec-Gateway mindestens einen Durchsatz von 34 Mbit/s haben und das vor allem bei der maximal bentigten Anzahl von Tunneln, mit Triple-DES, SHA1 und IPSec Compression. Falls Sie sich nicht im Klaren darber sind, wie sehr das VPN im Laufe der Zeit wachsen wird, knnen Sie auch Systeme einsetzen, die mit weiteren Schnittstellenkarten und Hardwarebeschleunigern aufrstbar sind. Bandbreitenmanagement Das Bandbreitenmanagement ist eine Methode, um bestimmten virtuellen Verbindungen innerhalb einer physikalischen Verbindung bestimmte Bandbreiten zuzuteilen, beziehungsweise diese zu begrenzen. Damit soll verhindert werden, dass bestimmte Verbindungen anderen Verbindungen bentigte Bandbreite wegnehmen.
344
Die Realisierung
Gutes Bandbreitenmanagement erlaubt die Zuteilung von maximalen Bandbreiten und so genannten Burst Rates, die festlegen, um wie viel dieser Wert berschritten werden darf, wenn die gewnschte Bandbreite zur Verfgung steht. Das Ziel des Ganzen ist es, auf der einen Seite bestimmten Tunneln eine Mindestbandbreite zu garantieren, aber auf der anderen Seite auch mglichst alle verfgbare Bandbreite auszunutzen. Lastverteilung Eine andere Mglichkeit ist die, dass man sich fr VPN-Gateways entscheidet, die ein so genanntes Loadbalancing, also eine Lastverteilung zwischen den Systemen, untersttzen. Damit kann man, falls erforderlich, die Systemleistung durch zustzliche Gerte erhhen und kommt auch gleichzeitig in den Genuss einer gewissen Redundanz. Admission Control Speziell in Remote-Access-VPNs, die man ja sehr oft berbucht, sollte man Prioritten fr bestimmte Benutzerklassen vergeben knnen, die festlegen, mit welchem Vorrang sich ein Benutzer am VPN-Konzentrator anmelden darf. Analog zur QoS hinsichtlich der Weiterleitung von Paketen hat man hier ein Merkmal, mit welcher Prioritt Anmeldeversuche erfolgen und welche Ressourcen das VPN-System fr die verschiedenen Priorittsklassen bereit stellt. Im Idealfall kann man sogar der hchsten Priorittsklasse unter gewissen Umstnden einen Zugang garantieren. Flussbasierende Qualitt (RSVP) In Kapitel 3 wurden bereits die verschiedenen Arten von Quality-of-Service (QoS) angesprochen, so dass wir uns hier auf ihren praktischen Einsatz konzentrieren knnen. Eine flussbasierende Ende-zu-Ende-Qualitt mit RSVP wird meist nicht von Internet-Routern untersttzt, so dass zwischen den beteiligten Systemen Strecken existieren knnen, die eine Weiterleitung der Pakete nach dem Best-Effort-Prinzip vornehmen. Nichtsdestotrotz bieten manche Hersteller RSVP an, um mindestens im VPNGateway selbst eine entsprechende Priorisierung vorzunehmen. Damit kann man eventuell knappe Bandbeiten differenzierter bestimmten Benutzerklassen zuteilen. Wichtiger ist jedoch der Fokus auf klassenbasierende Qualitt. Klassenbasierende Qualitt (DiffServ) Differentiated Services (DiffServ) hat sich als Standard fr QoS im Internet bzw. an dessen Grenze, also am Schnittpunkt zwischen Provider und Kunde, weitgehend durchgesetzt. Auch im Intranet ist es das QoS-Protokoll der Wahl,
345
10 VPN-Design
und viele LAN-Switches untersttzen bereits DiffServ. Es bietet sich daher an, die eigene QoS-Strategie ber die Grenzen der eigenen Intranets hinaus bis in das Internet zu erweitern. Allerdings ist im Fall von IPSec eine Sache zu beachten, und zwar bevor man sich ein VPN-Gateway beschafft: Denn hier muss das VPN-Gateway als DiffServ-Edge-Router die IP-Pakete entsprechend der QoS-Policy markieren, falls das nicht bereits an anderer Stelle im Netzwerk erfolgt ist. Denn nach dem Tunneling und der Verschlsselung der Daten kann der DiffServ-Edge-Router keine Markierungen mehr aufgrund von Protokoll- oder Portnummern des Originalpakets setzen, da es verschlsselt ist. Das einzige, was der Provider erkennen kann, ist das DS-Byte im ueren IP-Header. Und in dieses Byte wurde vor der Verschlsselung des Originalpakets dessen DS-Byte kopiert.
10.9.7
Sicherheitsstrategie und Firewalls
Sie werden im Folgenden fter den Ausdruck dediziertes oder echtes VPN-Gateway lesen. Damit soll ausgedrckt werden, dass ein solches System (vgl. Abbildung 10.7) speziell fr den VPN-Einsatz entwickelt wurde und einige wichtige Eigenschaften besitzt: Es kann keine IP-Pakete, auch nicht gefiltert, zwischen seinem ffentlichen Interface (Internet) und seinem privaten Interface (Intranet) bertragen. Dieser Zustand kann auch nicht durch Systemeinstellungen gendert werden. Sein ffentliches Interface ist ein spezieller IP-Stack, der nur Pakete der zu verarbeitenden Tunneling- oder Security-Protokolle verarbeitet. Diese Eigenschaften sind essenziell, wenn man ein VPN ohne weitere komplexe und damit fehleranfllige Manahmen wirklich sicher machen will. Ein dediziertes VPN-Gateway kann somit weder als Router noch als Firewall benutzt werden. Andere, also gewissermaen unechte Arten von VPN-Gateways sind zum Beispiel Router, die durch ein Softwaremodul eine IPSec-Zusatzfunktionalitt bekommen haben. Auf diesen Systemen kann ber ein ffentliches Interface sowohl normaler Datenverkehr mit allen denkbaren Protokollen als auch IPSec bertragen werden. Ohne weitere spezielle Sicherheitsmanahmen auf dem ffentlichen Interface ist solch ein System natrlich eine Sicherheitslcke erster Klasse. Dass normale Paketfilter keinen Schutz vor ernsten Hackerangriffen bieten, ist ja hinlnglich bekannt. Wenn nicht im Router selbst, so muss zumindest zwischen ihm und dem Intranet eine Firewall arbeiten, aber der Router ist dann vllig ungeschtzt. Also hat man hier insgesamt einen erheblichen Aufwand zu betreiben und hat trotzdem nicht den Schutz, den ein echtes VPN-Gateway bieten kann.
346
Die Realisierung
VPNGateway
Internet
ffentliches Interface Privates Interface
Intranet
VPN-Gateway
Gehrteter IP-Stack (IPSec) Pass: Protokoll 50/na Protokoll 51/na Protokoll 17/500
UniversalIP-Stack + Paketfilter
Krypto-Modul (IPSec, DES, 3-DES, SHA1, )
Tunnel-Encapsulation Tunnel-Decapsulation
Bandwidth Management und QoS (DiffServ)
Abbildung 10.7: Ein dediziertes VPN-Gateway
Die Einfhrung eines VPNs mit seinen VPN-Gateways scheint oft in einem Konflikt zur aktuellen Sicherheitspolitik zu stehen oder einen direkten Einfluss auf den Einsatz oder die Funktion von Firewalls zu haben. Aber das stimmt nicht, hier trgt der Schein. Ein VPN hat grundstzlich, wenn es als Remote-Access-VPN und/oder Branch-Office-VPN eingesetzt wird, absolut keinen Einfluss auf irgendetwas, das die Firewall eines Unternehmens betrifft. Denn hier wird lediglich eine alte Technologie bei gleicher Funktionalitt durch eine neue ersetzt es ndert sich bei guter Migration nichts Sicherheitsrelevantes. Wenn beispielsweise ein Frame-Relay-VPN durch ein IP-VPN ersetzt wird und die neue Technologie, z.B. durch IPSec, eine hhere Sicherheit als vorher garantiert, dann ergibt sich daraus kein Einfluss auf eine Firewall, und man geht weiterhin mit der Sicherheitsstrategie konform. Auch die Theorie, mit einem VPN wrde man einen Internetzugang schaffen, ist unsinnig, es sei denn, man setzt die falschen Systeme dafr ein zum Beispiel eine Firewall. Dann trifft dieser Satz tatschlich zu. Falls man einen Standardrouter mit IPSec aufrstet und als IPSec-Security-Gateway missbraucht, trifft dies auch zu. Echte, dedizierte IPSec-Security-Gateways ermglichen kein direktes Forwarding von IP-Paketen vom Internet ins Intranet auch nicht durch falsche Konfiguration! Eine Firewall und ein Router tun dies schon, das sollte man sich immer vor Augen halten.
347
10 VPN-Design
Intranet
VPNGateway
Internet
VPNGateway
Intranet
Firewall
Internet
Intranet
Abbildung 10.8: Der kleine Unterschied: Ein VPN-Gateway verbindet private Netze miteinander, eine Firewall verbindet private Netze mit dem Internet.
An dieser Stelle ist ein wichtiger Sicherheitstipp angebracht: Es gibt VPN-Gateways mit speziellen gehrteten, sicheren IP-Stacks, auf denen man als Option Firewallsoftware installieren kann, um diese damit gleichzeitig als Firewall nutzen zu knnen. Allerdings booten diese Systeme anschlieend mit neuen Standard-IP-Stacks, und die ganze schne Sicherheit des Stacks ist dahin und auf eine hhere Ebene, die der Firewall, verlagert. Auerdem haben solche Systeme ohnehin nicht den vollen Funktionsumfang guter Firewalls. Meist reduziert er sich auf zustandsabhngiges Filtern von IP-Paketen (Stateful Packet Inspection). Wichtige Funktionen wie Application Level Gateways fehlen meist. Deshalb kann ich Ihnen nur dringend ans Herz legen, eine Firewall nicht mit einem VPN-Gateway in einem System zu kombinieren. Eine Firewall und ein VPN-Gateway sind zwei vllig unterschiedliche Systeme mit vllig gegenstzlichen Aufgaben. Eine Firewall steuert und kontrolliert den Verkehr zwischen Internet und Intranet. Ein echtes dediziertes VPN-Gateway erlaubt nur den Datenverkehr zwischen den Netzen des Intranets es gibt keine Verbindung in das Intranet. Deshalb sollten Firewall und VPN immer getrennt werden. Auch wenn es auf den ersten Blick die teurere Lsung zu sein scheint, es ist garantiert die bessere und sicherere Lsung. Wie kombiniert man aber nun ein dediziertes VPN-Gateway mit einer Firewall? Da gibt es verschiedene Anstze, von denen aber nur einer richtig Sinn macht. Diesen Ansatz sehen Sie in dem Beispiel in Abbildung 10.9. Das VPNGateway ist hier praktisch parallel zur Firewall geschaltet. Damit gibt es vor allem keine Performanceprobleme. Sicherheitstechnisch sieht die Sache zwar auf den ersten Blick nach einer Umgehung der Firewall aus, sie ist aber keine
348
Die Realisierung
Umgehung. Denn das VPN-Gateway kommuniziert ausschlielich ber Tunneling-Protokolle, im Fall eines Internet-VPN praktisch ausschlielich ber IPSec, mit anderen VPN-Gateways des Unternehmens oder mit VPN-Clients von Mitarbeitern des Unternehmens. Verbindungen in das Internet sind unmglich. Also liegt vom Standpunkt der Sicherheit auch keine Umgehung der Firewall vor.
VPNGateway
ISP-AccessRouter
Internet
Firewall
Intranet
ffentliche Server
DMZ, Demilitarized Zone
Abbildung 10.9: Die sinnvolle Kombination von VPN-Gateway und Firewall
Die Idee, eine Firewall vor ein IPSec-Gateway zu setzen, kann man auch nach kurzem Nachdenken wieder vergessen. Denn eine Firewall soll ja die Pakete prfen, die in das Intranet gelangen. Diese Pakte sind aber in einem anderen IP-Paket eingekapselt und verschlsselt, die Firewall kann weder den Inhalt, die Port- oder Protokollnummer noch die IP-Adressen erkennen. Sie kann einfach nur IPSec-Pakete von und zum Gateway transportieren, ohne eine Prfung vorzunehmen. Sicherheitstechnisch bringt dies also gar nichts, aber dafr muss der ganze VPN-Verkehr ber die Firewall transportiert werden, und diese droht damit zu einem Engpass zu werden. Falls jedoch die Firewall unbedingt vor ein VPN-Gateway gesetzt werden muss, dann muss je nach Tunneling-Protokoll eine Reihe von Ports und Protokollen, die Sie in Tabelle 10.7 aufgelistet sehen, auf der Firewall freigegeben werden. Was berhaupt nicht funktioniert, ist, eine normale Firewall hinter ein echtes VPN-Gateway zu setzen. Denn die Firewall soll ja gerade bestimmten Verkehr wie HTTP, FTP usw. filtern und durchlassen. Allerdings werden alle Pakete solcher Applikationen bedingungslos von einem dedizierten VPN-Gateway im ffentlichen Interface verworfen und gelangen niemals bis zur Firewall. Und normale Webserver oder FTP-Sites arbeiten nicht mit IPSec oder anderen Tunneling-Protokollen.
349
10 VPN-Design
Protokoll IPSec ESP IPSec AH IKE PPTP Control Connection PPTP Data Encapsulation L2TP L2F
Protokoll 50 (ESP) 51 (AH) 17 (UDP) 6 (TCP) 47 (GRE) 17 (UDP) 17 (UDP)
Source-Port Nicht benutzt Nicht benutzt 500 > 1023 Nicht benutzt > 1023 > 1023
Destination-Port Nicht benutzt Nicht benutzt 500 1723 Nicht benutzt 1701 1701
Tab. 10.7: Eine bersicht, welche Protokoll- und Portnummern freizugeben sind, wenn sich eine Firewall vor dem VPN-Gateway befindet
Eine Ausnahme, die Sie in Abbildung 10.10 sehen, ist ein mglicher Einsatz von VPN-Technologie fr Extranets. Der Grundansatz eines VPN ist es ja, ein privates Netz zu haben, das lediglich ffentliche Netze als Transportmedium benutzt. Somit mssen in VPN-Gateways genau so wenige oder so viele Zugriffsbeschrnkungen auf Benutzerebene existieren wie in normalen Routern oder Remote-Access-Konzentratoren. Die ganze Sicherheitstechnologie in VPN-Systemen dient ausschlielich zur Sicherung der virtuellen Verbindung und gegenseitigen Authentifizierung.
VPNGateway
Eigene Mitarbeiter
Extranet-Benutzer
ISP-AccessRouter
Internet
Firewall
Intranet
ffentliche Server
DMZ, Demilitarized Zone
Abbildung 10.10: Im Extranet greifen externe Benutzer des VPN ber eine nachfolgende Firewall kontrolliert auf das Intranet zu.
Soll das Ganze auch auf ein Extranet erweitert werden, so ist damit das private Netz auch anderen Personen oder Organisationen zugnglich. Fr diese gelten natrlich vllig andere Kriterien als fr die eigenen Mitarbeiter. Eine
350
Die Realisierung
brauchbare Lsung fr dieses System ist die Kombination der Funktionen eines VPN-Gateways mit einer in den meisten Unternehmen ohnehin vorhandenen Firewall. In dem Beispiel in Abbildung 10.10 greifen die externen Benutzer ebenfalls ber sichere IPSec-Tunnel auf das VPN-Gateway zu. Die entkapselten und entschlsselten IP-Pakete werden jedoch nicht direkt in das Intranet geleitet, sondern zuerst zur Firewall gefhrt und dort entsprechend den Sicherheitsrichtlinien verarbeitet. Nur die eigenen Mitarbeiter werden direkt mit dem Intranet verbunden. Somit erfolgt auch hier eine konsequente Umsetzung der beiden verschiedenen Zielrichtungen von VPN und Firewall, indem man die VPN-Technologie zum sicheren Transport privater Daten durch ffentliche Netze einsetzt und die Firewall benutzt, um den Verkehr von und zu potenziell unsicheren Gegenstellen zu steuern und zu kontrollieren.
10.9.8
Authentifizierungsverfahren
Bei den Authentifizierungsverfahren muss zwischen der gegenseitigen Authentifizierung zweier Endsysteme (z.B. VPN-Gateways) und der Authentifizierung von Benutzern an einem Zugangskontrollsystem unterschieden werden, obwohl dies manchmal in einem Gert oder sogar funktionell miteinander kombiniert wird. In Internet-VPNs sind beide Verfahren wichtig, um das VPN-System selbst zu schtzen und um im Weiteren ein unerlaubtes Eindringen in das Unternehmensnetz zu verhindern. Benutzer-Authentifizierung Bei der Benutzer-Authentifizierung ist die Sicherheitsstrategie des Unternehmens gefragt, die fr den Fernzugriff auf das Unternehmensnetz bestimmte Richtlinien festlegt. Es sollten mindestens die gleichen Verfahren wie im bisherigen Remote Access eingesetzt werden knnen. Falls dort jedoch eine einfache Passwort-Authentifizierung erfolgt, sollte man berlegen, gleich oder spter eventuell strkere Verfahren einzusetzen, oder zumindest darauf vorbereitet sein. Strkere Verfahren (vgl. Kapitel 5) sind solche, die zwei oder mehr Verfahren miteinander kombinieren. Beim Remote Access haben sich Token-Karten bisher einer groen Beliebtheit als Werkzeug zur starken Authentifizierung erfreut. Diese sollte man auch im VPN weiter benutzen knnen. Neuere Authentifizierungsverfahren, die auf digitalen Zertifikaten beruhen, werden oft pauschal als starke Authentifizierung bezeichnet. Das sind sie aber nur, wenn sie auch korrekt eingesetzt werden. Im Fall von digitalen Zertifikaten bedeutet dies, dass der private Signaturschlssel eines Anwenders nicht auf einem Rechner gespeichert sein darf, sondern nur auf einem externen Medium, das der Benutzer in seine persnliche Verwahrung nehmen
351
10 VPN-Design
kann. Ein solches Medium sind zum Beispiel Chipkarten oder in mglichst zu vermeidenden Ausnahmefllen auch Speicherkarten oder Disketten. System-Authentifizierung IP Security schreibt zwingend nur ein einziges Authentifizierungsverfahren vor: Die Authentifizierung mit einem Pre-Shared Secret. Jedoch sollten auch weitere Verfahren, insbesondere digitale Signaturen untersttzt werden. Allerdings kann man mit guten Pre-Shared Secrets auch einen wirkungsvollen Schutz gegen Wrterbuchangriffe erreichen. Denn bei der Authentifizierung von IPSec-Systemen untereinander ist kein Anwender involviert, der Schwierigkeiten htte, sich eine hexadezimale Zeichenkette wie etwa 0x02f6ad32ff027ea53b zu merken. Die meisten vernnftigen IPSec-Gateways erlauben daher die Eingabe sehr langer hexadezimaler Zeichenketten, so dass ein Rateangriff darauf leicht die Komplexitt eines Angriffs auf einen 128-Bit-Schlssel erreichen kann. Wenn ein VPN-Gateway in einer sicheren Umgebung betrieben wird und das Management ebenfalls sicher (verschlsselt und stark authentifiziert) erfolgt, dann kann ein solches Pre-Shared Secret auch durchaus mehrere Quartale oder sogar Jahre gleich bleiben. Gute IPSec-Systeme erlauben auch noch eine oder mehrere andere Arten der Authentifizierung, die auf Public-Key-Verfahren beruhen, zum Beispiel digitale Signaturen. Hierbei werden fr die beteiligten VPN-Gateways von der Certificate Authority (CA) digitale Zertifikate ausgestellt.
10.9.9
Die Auswahl von Service Providern
Das, was viele befrchtet hatten, ist eingetreten: Es gibt Internet Service Provider, die ihren Kunden den Betrieb eines VPN verwehren. Dies tun sie ganz einfach, indem zum Beispiel UPD-Pakete mit der Portnummer 500 blockiert werden, wodurch kein IKE-Protokoll laufen kann. Wenn man die rechtlichen Implikationen durch bestehende Vertrge und die Geisteshaltung solcher Provider (manche reden schon von einer regelrechten Zensur, man drfe nur noch das bertragen, was dem ISP passt) einmal beiseite lsst, ergeben sich hieraus zwei wichtige Punkte, die Sie beachten sollten, wenn Sie einen Provider auswhlen und einen entsprechenden Vertrag abschlieen: 1. Der Provider muss sich vertraglich festlegen, keine Pakete zu filtern. Da gibt es kein Wenn und kein Aber. 2. Er muss Ihnen garantieren, dass die Pakete ausschlielich in seinem Netz oder anderen Netzen ebenfalls ohne Filterung transportiert werden. Die weiteren Kriterien sind recht unterschiedlich zu bewerten, da gibt es kein allgemein gltiges Rezept. Sie mssen aber die folgenden Punkte klren, um einen Provider zu bewerten:
352
Die Realisierung
Die Gre des Providers Die Kosten fr das VPN, die an den ISP zu entrichten sind Betreibt der Provider einen eigenen Internet-Backbone? Welche bergangspunkte betreibt er national und international? Mit welchen Providern kooperiert er? Ist eine weltweite Einwahl mglich? Betreibt er auch Sprach- oder Mobilnetze? Wie sehen seine bisherigen Werte (Verfgbarkeit, Bandbreiten usw.) aus?
10.9.10 Service Level Agreements

Leider gibt es auch fr die Service Level Agreements (SLA) keine allgemein gltigen Vorlagen oder Vorgaben. Diese hngen auch von dem Provider ab. Je nach eingesetzter Technologie, Gre, eigenen Sprach- und Datennetzen knnen die unterschiedlichsten Leistungen angeboten werden. Ein Provider, der kein eigenes Netz betreibt, hat Probleme, solche Vertrge abzuschlieen, die Vereinbarungen enthalten, deren Einhaltung einen Zugriff auf das Netzwerk erfordert. Es gibt eine ganze Reihe von Punkten, die in ein SLA einflieen knnen. Nicht alle passen in jedes Netzkonzept, und es gibt auch mit Sicherheit ein paar Details, die in der folgenden Aufstellung noch fehlen mgen. Verfgbarkeit Bei den Verfgbarkeitswerten wird blicherweise noch etwas weiter differenziert. Dies spiegelt auch etwas die Art und Qualitt der beim Provider eingesetzten Systeme wider. In Backbones werden oft optische Systeme eingesetzt oder digitale Telefonnetze mitbenutzt, die eine extrem hohe Verfgbarkeit aufweisen. Im Access-Bereich hingegen stehen bei den Kunden oft kostengnstige Router als bergabepunkte zur Verfgung, denen man bereits ansieht, dass sie vermutlich keine Verfgbarkeit von 99,999% garantieren knnen.
Backbone-Verfgbarkeit Hier warten die Service Provider mit den hchsten
Werten auf. Sie bewegen sich dabei im Bereich von 99,7% bis 99,9%. Aus dem Vertrag sollte hervorgehen, was der Provider unter dem Begriff Backbone versteht und welche Ausdehnung der Backbone hat.
Einwhlverfgbarkeit Hiermit wird die Verfgbarkeit des Einwhldienstes
beschrieben. Sie sollten in jedem Fall klren, ob ein Besetzt-Fall als nicht verfgbar im Sinne des Vertrags anzusehen ist. Ein Besetzt-Fall liegt zum Beispiel
353
10 VPN-Design
dann vor, wenn alle Einwahl-Ports des Providers belegt sind und das Telefonnetz einen besetzten Anschluss signalisiert.
Ende-zu-Ende-Verfgbarkeit Das ist die Verfgbarkeit, die in einem Branch-
Office-VPN wirklich zhlt. Anzustreben sind auch hier Werte im Bereich von 99,5% und mehr. Dieser Wert scheint auf den ersten Blick hoch zu sein. Hier hilft vielleicht die folgende kleine Rechnung, um diesen Wert ins rechte Licht zu rcken: Ein Jahr hat 365 x 24 = 8760 Stunden. Eine Verfgbarkeit von 99,5% bedeutet, dass an maximal 43,5 Stunden im Jahr die Verbindung nicht zur Verfgung steht. Statistisch gesehen verteilt sich das auf etwa 250 Arbeitstage, so dass sich maximal 29,5 Stunden Ausfall auf die Arbeitstage verteilen. Das kann unter Umstnden schon zu viel sein, insbesondere dann, wenn auch nachts Datenverbindungen fr irgendwelche Hintergrundverarbeitungen oder Zugriffe aus anderen Zeitzonen erfolgen. Allerdings bedeutet eine Verfgbarkeit von 99,5% nicht, dass das Netz tatschlich 43,5 Stunden pro Jahr ausfllt, es ist nur ein maximal zulssiger Wert. Oft ist die tatschliche Verfgbarkeit hher. Maximale Paketverzgerung zwischen bergabepunkten Dieser Wert kann fr bestimmte Applikationen sehr kritisch sein. Insbesondere interaktive Sprache und Video sind da sehr empfindlich, jedoch auch ltere Online-Applikationen oder Netzwerkapplikationen, die offensichtlich nur fr LANs entwickelt wurden. Anzustrebende Werte fr Sprache und Video sollten unter 100 ms liegen. Insbesondere wenn ein VPN bei einem einzigen Provider betrieben wird, sind solche Werte auch mglich. Bandbreiten Hier wird festgelegt, mit welchen garantierten Bandbreiten der Zugriff auf das Netz des Providers mglich ist. Die Werte liegen maximal bei der Geschwindigkeit der Zugangsverbindung und werden manchmal tatschlich auch von Providern garantiert. Maximale Fehlerrate Die Hhe des Verhltnisses zwischen korrekt bertragenen und fehlerhaften oder fehlenden IP-Paketen sollte auch festgelegt werden. Ursachen fr Paketverluste sind meist berlastsituationen, in denen ATM- und Frame-RelayNetze anfangen, Pakete zu verwerfen. Das Verhltnis sollte hier wenigstens 99,98% betragen. Mittlere und garantierte Reparaturzeiten Ein Tipp vorweg: Lassen Sie sich nicht auf so genannte Reaktionszeiten in einem SLA ein. Es sei denn, der Begriff Reaktion ist im Vertrag genau definiert und bedeutet Reparatur. Denn eine Reaktionszeit von drei Stunden bedeutet
354
Die Realisierung
im fr den Kunden schlimmsten Fall, dass er ein Problem meldet und dass drei Stunden spter jemand reagiert, indem er zurckruft und fragt, was los ist. Was genau festgelegt werden muss, ist die Zeit, die maximal zwischen Problemmeldung und Problembehebung vergehen darf. Die Zeit richtet sich nach den Anforderungen des Kunden, oft werden vier Stunden vereinbart, ein Wert, mit dem beide Seiten leben knnen. Mittlere und garantierte Installationszeiten Ein Netzwerk ist niemals fertig. Ein VPN auch nicht. Es werden laufend neue Standorte angebunden, zustzliche Kunden und Partner in Extranets aufgenommen und neue Remote-Access-Benutzer angelegt. Es muss daher vertraglich festgelegt werden, wie lange solche Prozesse maximal dauern drfen. Die Zeiten richten sich nach verschiedenen Faktoren, wobei sehr kurze Zeiten fr Hardware-Installationen bedingen, dass der ISP die Gerte vorhalten muss, wodurch das SLA sehr teuer werden kann. Realistische Werte sind ein bis zwei Monate von der Bestellung bis zur Bereitstellung. Das Anlegen eines Remote-Access-Kontos sollte bei einem ISP maximal einen Tag dauern drfen. QoS-Klassen und Behandlung der Pakete Falls der Service Provider Quality-of-Service auf IP-Ebene untersttzt, muss man vereinbaren, welche Arten von IP-Paketen in welche Qualittsklassen des Service Providers gehren. Am einfachsten ist es, wenn die Klassifizierung bereits im Netz des Kunden erfolgt und der ISP nur noch das DS-Byte der IP-Pakete auswerten und umsetzen muss. Dies ist beim Einsatz von IPSec auch gleichzeitig die einzige Mglichkeit. Keine Paketblockierung Legen Sie fest, dass der Provider keine Datenpakete blockieren darf. Am sichersten sind Sie, wenn die Vereinbarung dahin gehend lautet, dass berhaupt keine Filterung stattfindet. Vertragsstrafen bei Nichteinhaltung Das ist der kitzlige Punkt schlechthin. Hier mssen zwei Dinge festgelegt werden: 1. Wann liegt berhaupt eine Nichterfllung des SLA in welchem Umfang vor? 2. Wie hoch sind die Vertragsstrafen fr die jeweiligen Vertragspunkte? Der erste Punkt scheint eigentlich klar zu sein, jedoch gibt es bei genauem Hinsehen eigentlich nur Probleme. Denn die Frage ist, welche Messverfahren von wem eingesetzt werden, wie zuverlssig und aussagekrftig diese sind und ob sie von beiden Seiten anerkannt werden.
355
10 VPN-Design
Der einzige Weg, der Erfolg verspricht, besteht darin, die komplette Messtechnik fr alle im SLA spezifizierten Punkte genauestens im Service Level Agreement festzulegen. Zustzliche Dienste Einige Provider bieten zustzliche Dienste an, die die Qualitt des Internetzugriffs und die Sicherheit beeinflussen knnen.
Dial-In QoS Manche ISPs betreiben bereits Systeme, mit denen Datenpakete im POP (oder einem virtuellen POP) aufgrund der User-ID und der eingesetzten Applikationen fr QoS (DiffServ) markiert werden knnen. Diese Dienste knnen ebenfalls in einem SLA festgelegt werden. Dial-In Firewall Es ist mit der obigen Technik auch mglich, Benutzerkonten
so zu konfigurieren, dass bestimmte Dienste oder Inhalte, die vom Kunden spezifiziert werden knnen, in den Datenpaketen herausgefiltert werden.
Dial-In Compulsory Tunneling Tunneling-Protokolle wie IPSec sind Vertreter des freiwilligen Tunneling. Ein Anwender knnte zum Beispiel seinen IPSec-Client gar nicht benutzen und sein Firmen-Internetkonto bei einem Service Provider benutzen, um per Einwahl ber den POP des Providers in das Internet zu gehen. Der Service-Provider kann dem Kunden aber garantieren, dass der Benutzer, sobald er sich in den POP des ISP einwhlt, zwangsweise zum Kundennetzwerk getunnelt wird.
10.10 Beispiele
10.10.1 Remote-Access-VPN
In Abbildung 10.11 bis Abbildung 10.13 sehen Sie einen stufenweisen Umstieg von einem reinen Remote Access zu einem Remote-Access-VPN. Es wurde dabei eine Netzwerkumgebung aus der echten Welt zugrunde gelegt. Der Remote-Access-Konzentrator kann digitale und analoge Rufe terminieren. Folgende Einwahltechnologien sind mit heute blichen Standard-RemoteAccess-Konzentratoren mglich: Analoge Modemeinwahl mit allen blichen Protokollen bis 56 Kbit/s Synchrones ISDN Asynchrones ISDN mit V.120-Protokoll GSM ber analoge Modememulation
356
Beispiele
GSM ber ISDN mit V.110-Protokoll X.75 wird gelegentlich noch angeboten, aber praktisch nicht mehr eingesetzt. Nicht untersttzt werden so genannte High-Speed-Zugnge per DSL oder Modems fr Fernsehbreitbandkabel.
Homeoffice
ISDN ISDN
Homeoffice
RADIUSServer
Zentrale
RemoteAccessKonzentrator Router
ISDN PSTN
8 x S2M
Public Server (www, ftp)
Firewall
DHCP-Server
DMZ
Internet
3 x 2 Mbit/s
NetzwerkManagement
Router
Abbildung 10.11: Der Remote Access soll durch VPN-Technologie realisiert werden.
In der bergangsphase (siehe Abbildung 10.12) werden beide Welten, der Remote Access und das Remote-Access-VPN, parallel betrieben. Die Benutzer installieren nach und nach den IPSec-Client auf ihren Rechnern. Gleichzeitig werden vom Unternehmen bei einem oder mehreren ISPs Benutzerkonten fr die User angemeldet. Der Remote-Access-Konzentrator benutzt RADIUS zur Benutzer-Authentifizierung und bezieht seine IP-Adressen, die er den Clients ber PPP zuweist, aus einem DHCP-Server. Der VPN-Konzentrator wurde so ausgesucht, dass er die gleichen Verfahren einsetzen kann, dass also kein zustzlicher Managementaufwand ntig ist und die Benutzer ihre User-ID und Passwrter sowohl fr den Remote Access als auch fr das VPN einsetzen knnen.
357
10 VPN-Design
Homeoffice ISDN
Homeoffice ISDN
RADIUSServer
Zentrale
RemoteAccessKonzentrator Router
ISDN PSTN
4 x S2M VPNKonzentrator Public Server (www, ftp)
Firewall
DHCP-Server
DMZ
Internet
34 Mbit/s Router
NetzwerkManagement
Abbildung 10.12: In der bergangsphase werden beide Technologien parallel eingesetzt.
Homeoffice
VPNRouter
Homeoffice
VPNRouter ISDN
RADIUSServer
ISDN
VPNClient
Router
DSL
VPNKonzentrator
VPNClient
Internet
VPNClient
Public Server (www, ftp)
Firewall
DHCP-Server
DMZ
NetzwerkManagement
34 Mbit/s
VPNClient
Router
Abbildung 10.13: Das Remote-Access-VPN
358
Beispiele
In der letzten Phase (siehe Abbildung 10.13) wird der alte Remote-AccessDienst eingestellt und nur noch das VPN benutzt. Zustzlich knnen die Anwender auch neue Zugangstechnologien einsetzen, falls die Provider diese anbieten. Insbesondere DSL ermglicht um ein Vielfaches hhere Datenraten. In manchen Regionen wird auch der Internetzugang ber das TV-Kabel mit speziellen Modems angeboten. Auch hierbei sind wesentlich hhere Geschwindigkeiten als mit ISDN mglich.
10.10.2 Branch-Office-VPN
Die Umstellung auf ein Branch-Office-VPN fllt noch einfacher aus, da hier keine Umstellungen fr die Benutzer notwendig werden. Hier knnen whrend eines Wartungsfensters die Systeme schrittweise ausgetauscht werden. In Abbildung 10.14 wird ein Routernetzwerk, das drei Standorte miteinander ber Standardfestverbindungen verbindet, durch ein IP-VPN ersetzt.
Router-3 Netz C Router-1 Netz A
Standardfestverbindung Standardfestverbindung
Router-2 Netz B
Router-3
Internet
Router-1 Netz A
Tunnel
Netz C
VPN-Gateway GW-2 Netz B
VPN-Gateway GW-1
VPN-Gateway GW-3
Internet
Netz A
VPN-Gateway GW-1 Tunnel Tunnel VPN-Gateway GW-2
Netz C
Netz B
Abbildung 10.14: Der schrittweise Aufbau eines Branch-Office-VPN
359
10 VPN-Design
10.10.3 IP-VPN-Service eines ISP

Die beiden oben stehenden Beispiele knnen auch als komplette Dienstleistung von Service Providern zur Verfgung gestellt werden. In den Fallstudien im bernchsten Kapitel finden Sie mehr zu diesem Thema, deshalb ist dieser Teil hier etwas krzer angelegt. Generell kann man bei den Service Providern zwischen zwei verschiedenen Modellen whlen, die jedoch noch in verschiedene Angebotspakete unterteilt werden knnen: Internet Access Hier stellt der Provider nur den Zugriff auf das Internet bereit. In der komfortablen Version dieses Angebots installiert und betreibt er auch einen AccessRouter beim Kunden und beschafft und berwacht auch die Zugangsleitungen zu seinem POP. Managed Service Hier geht die Dienstleistung noch einen Schritt weiter: Der ISP betreibt neben dem Internetzugang auch die VPN-Systeme des Kunden. Der Kunde selbst verwaltet nur seine Benutzer- und Gruppenprofile, den Rest macht der Provider.
360
11
Auswahl der VPN-Komponenten
Irgendwann kommt der Punkt, da muss man seine Vorberlegungen, seine Wnsche und Vorstellungen in einem oder mehreren Produkten wiederfinden. Wie kann man nun an die Auswahl der Komponenten herangehen und alles richtig oder mglichst wenig falsch machen? Ein fertiges Rezept gibt es nicht, da sind die mglichen Rahmenbedingungen zu unterschiedlich, der Markt und die Technologie zu dynamisch. Man kann aber strukturiert an die Sache herangehen, sich ber sein Anforderungsprofil im Klaren sein und dann eine Auswahl treffen. Wenn Sie jetzt erwarten, an dieser Stelle die in hnlichen Bchern oft publizierten Hersteller- und Produktbersichten zu finden, werden Sie vielleicht ein klein wenig enttuscht sein. Aber dies hat eine Reihe gewichtiger Grnde: 1. In der Zeit, die von der Erstellung des Manuskripts bis zum Erscheinen dieses Buches vergangen ist, haben vermutlich alle Hersteller eine neue Software-Release freigegeben, vielleicht neue Gerte in das Portfolio aufgenommen oder gleich eine neue Firma mit ganz neuen Produkten bernommen. Also wre die bersicht berholt. 2. Eine solche bersicht kann einfach nicht vollstndig sein, weder in Hinblick auf die Hersteller noch in Hinblick auf deren Produkte und Leistungsmerkmale. 3. In einer umfangreichen bersicht kann man nicht alle Angaben der Hersteller berprfen, sondern muss deren Angaben einfach bernehmen. Und angesichts dessen, was da teilweise behauptet wird, drfen solche Angaben nicht durch ein Abdrucken in ernsthaften Abhandlungen aufgewertet werden. Es ist viel wichtiger, dass Sie in die Lage versetzt werden, die Angebote und Datenbltter der Hersteller kritisch zu beurteilen und die richtigen Fragen zu stellen. Aus diesem Grund wurde auch in diesem Kapitel nicht vom bisherigen Grundsatz der Herstellerneutralitt in diesem Buch abgewichen. Die Erstellung eines Pflichtenhefts ist eine hilfreiche Sache, die man nach seinem VPN-Design, wenn die Struktur, die Mengengerste, die Performanceanforderungen usw. feststehen, angehen sollte. In dem Pflichtenheft finden sich die Spezifikationen wieder, die die idealen VPN-Systeme aufweisen sollten, am besten nach dem Grad der Wichtigkeit aufgeschlsselt. Es gibt hchstwahrscheinlich kein Gert, das alle Kriterien so erfllt. Sie mssen das oder die Systeme auswhlen, die dem am nchsten kommen.
361
11 Auswahl der VPN-Komponenten
11.1 VPN, Feature oder dediziert?

Bevor Sie an die Aufstellung eines Pflichtenhefts fr die zu beschaffenden VPN-Komponenten gehen, sollten Sie eine grundstzliche Entscheidung treffen. Setzt man spezielle, dedizierte VPN-Systeme ein, oder rstet man vorhandenes WAN-Equipment mit VPN-Features aus? Dedizierte VPN-Systeme Dedizierte VPN-Systeme sind Gerte und Software, die ausschlielich zum Betrieb eines VPNs entwickelt wurden. Der Schwerpunkt des Designs liegt bei solchen Produkten im sehr schnellen Verarbeiten von Verschlsselungsalgorithmen und Tunneling-Protokollen. Um diese Kernfunktionalitten herum werden dann andere Funktionen wie Management, Quality-of-Service, Routing, Filterung und so weiter gruppiert. Der Vorteil dieses Ansatzes besteht darin, dass die kritischen Funktionen eines VPN mit sehr hoher Performance ausgefhrt werden. So finden sich in diesem Segment Gerte wieder, die ohne Hardwarebeschleunigerkarten bei 10.000 gleichzeitigen IPSec-Sicherheitsassoziationen mit starker Triple-DES-Verschlsselung fast 40 Mbit/s Datendurchsatz erreichen. Als weiterer Pluspunkt sind auch spezielle Implementierungen des Netzwerk-Stacks auf dem ffentlichen Interface mglich. Da ein dediziertes VPNSystem weder als Router noch als Firewall arbeiten muss, besteht auch keine Notwendigkeit, andere Protokolle als zum Beispiel IPSec auf dem ffentlichen Interface eines VPN-Konzentrators zu verarbeiten. Das Resultat ist eine sehr hohe Sicherheit solcher Systeme vor einer Vielzahl von IP-basierenden Angriffen. Access-Systeme mit VPN-Zusatzfunktionen Solche Systeme sind Gerte, deren Kernfunktionalitt nicht im Verschlsseln und Tunneling liegt, also Gerte wie Router, Einwhlkonzentratoren oder Firewalls. In solchen Systemen werden die entsprechenden Funktionalitten nachgerstet. Das Problem bei diesem Ansatz kann sein, dass das Gertedesign, sowohl von der Prozessorleistung als auch von der Busarchitektur und der Software her nur eine recht bescheidene Verarbeitungsleistung zulsst. Insbesondere Produkte, die schon vor einigen Jahren entworfen wurden, haben ihre liebe Not mit modernen VPN-Technologien, insbesondere mit starker Verschlsselung oder Public-Key-Verfahren. Der Grund besteht ganz einfach darin, dass vor fnf Jahren IPSec oder L2TP kein Thema bei der Entwicklung zum Beispiel eines Routers war.
362
Performance
Damit soll keineswegs gesagt werden, dass ein normaler Router als VPNGateway ungeeignet ist. Sie drfen aber auch keine Performancewunder erwarten, vor allem nicht im Vergleich mit reinen VPN-Systemen. Falls aber in bestimmten Fllen eine hohe Performance nicht erforderlich ist und die Gerte schon im Einsatz sind, spricht nichts gegen ihre Verwendung als VPNSystem.
11.2 Performance
Je nach Anwendungsgebiet und Applikationen besteht Bedarf an einem bestimmten Datendurchsatz, der, blicken Sie nur einmal auf die letzten fnf Jahre zurck, stndig und stark anwchst. Neue und immer mehr netzwerkzentrierte Anwendungen fordern mehr und mehr Bandbreite und neue Mglichkeiten, verschiedene Dienstklassen mit unterschiedlichen QoS-Parametern zu verarbeiten. Der reine Durchsatz von VPN-Systemen ist ein Schlsselfaktor, denn wenn er nicht ausreicht, bekommt man Probleme. Selbst die ausgefeilteste Quality-ofService-Technologie kann keine zustzliche Bandbreite erzeugen, sondern nur die vorhandene verwalten. Worin besteht aber das Problem? In jedem Datenblatt sind doch die Durchsatzwerte angegeben? Das Problem besteht einfach darin, dass meist aus den Datenblttern nicht hervorgeht, um welchen Wert es sich berhaupt handelt! Um eine Angabe ber den Datendurchsatz eines VPN-Systems richtig zu interpretieren, mssen Sie eine Reihe von Umstnden kennen, die diesen Wert beeinflussen: Wurde der Wert mit DES, Triple-DES oder vielleicht sogar ohne Verschlsselung ermittelt? Mit welchen Paketgren wurde gemessen? Wurden Datenmuster verwendet, die sich extrem leicht und schnell komprimieren lassen? Wie viele Tunnel waren gleichzeitig aktiv, und wurde ber alle parallel bertragen? War der Datenverkehr bidirektional oder unidirektional? In welcher Konfiguration wurde das Gert betrieben, also mit welcher Speichergre, mit oder ohne Beschleunigerkarten usw.? Befand sich das System in einem Standardbetriebszustand mit Logging, Accounting, Filterung usw., oder waren diese Prozesse deaktiviert? Bei geeigneter Auswahl der Testumgebung kann man Messungen in diesem Bereich um Grenordnungen variieren.
363
11.2.1
Eigene Messungen
Eigene Messungen sind entweder praxisfern oder sehr aufwendig, speziell wenn es um grere VPNs geht. Hier bentigt man ein entsprechendes Messinstrumentarium und sehr gute Kenntnisse ber die Technik, die man unter die Lupe nehmen will. Einfache Testaufbauten eignen sich nur bedingt. Insbesondere wenn es um hohe Datendurchstze geht, braucht man leistungsfhige Verkehrsgeneratoren und Software.
11.2.2
Verffentlichte Testberichte
Verffentlichte Testberichte muss man in zwei Kategorien unterteilen: solche, die von Herstellern stammen oder von ihnen in Auftrag gegeben wurden, und solche, die von unabhngigen Labors erstellt wurden, die meist im Auftrag von Fachzeitschriften ttig werden. Ein Paradebeispiel fr die erste Variante ist der Testbericht eines so genannten unabhngigen Testlabors, in dem vor zwei Jahren zwei VPN-Gateways verschiedener Hersteller miteinander verglichen wurden, eins mit zwei eingebauten Hardwarebeschleunigern und eins ganz ohne. Wer hat da wohl gewonnen, und vom wem wurde dieser Test wohl bezahlt? Tests in Fachzeitschriften sind da schon ernster zu nehmen, allerdings wird dort meist auch nur ein geringer Prozentsatz der am Markt erhltlichen Systeme getestet.
11.2.3
Beurteilungskriterien
Da man nur mit sehr hohem Aufwand eigene Messungen durchfhren kann, sind Sie leider letztendlich doch auf Messungen von Herstellern und Fachzeitschriften oder Testlabors angewiesen. Um diese etwas besser beurteilen zu knnen, werden im Folgenden ein paar Kriterien beschrieben, die einen starken Einfluss auf solche Messungen ausben. Systemkonfiguration Wurde das System in einem normalen Betriebszustand getestet, oder wurden alle nicht zur jeweiligen Messung bentigten, aber im normalen, produktiven Betrieb aktiven, Prozesse wie Logging, Accounting, Filterung usw. gestoppt? Weiterhin ist es ganz wichtig zu wissen, ob die getesteten Systeme mit Zusatzmodulen zur Beschleunigung von Verschlsselungsalgorithmen ausgerstet waren.
364
Performance
Verschlsselungsalgorithmen Selbstverstndlich hat die Art des eingesetzten Verschlsselungsalgorithmus einen ganz wesentlichen Einfluss auf die Performance. So ist Triple-DES knapp dreifach langsamer als DES mit 56 Bit. Aber Vorsicht, was wirklich zhlt, ist nicht der Triple-DES-Durchsatz, sondern die Verarbeitungsgeschwindigkeit der IPSec-Implementierung. Und die ist, als grobe Faustregel, bei IPSec-ESP mit Triple-DES, SHA1 und LZS-Komprimierung etwa um ein Drittel geringer. Ein Testbericht muss ausfhrlich Auskunft darber geben, was wirklich gemessen wurde. Eine Aussage wie Datenverschlsselung bis 100 Mbit sagt berhaupt nichts aus, auer vielleicht ber die Informationspolitik des betreffenden Herstellers. Hash-Algorithmen Bei den Hash-Algorithmen sollten Sie wissen, dass SHA1 je nach SoftwareImplementierung um bis zu 50% langsamer als MD5 sein kann. In einigen Hardwarebeschleunigern sind allerdings keine groen Unterschiede mehr vorhanden. Um ein System beurteilen zu knnen, sollte mglichst zur Messung SHA1 benutzt werden. MD5 ist mit Sicherheit nicht langsamer. CPU-Typ und Taktgeschwindigkeit Es ist klar, dass diese Werte einen direkten Einfluss auf den Systemdurchsatz haben. In einer Messung mssen diese Angaben enthalten sein. Cachegre und Speicherbus Auch dieser Faktor beeinflusst die Systemperformance: je grer und schneller, desto besser. Auch hier mssen die Angaben im Messprotokoll stehen, damit man auch das zu kaufende Gert entsprechend ausrsten kann. Speichergre Der Speicher ist ein noch wichtigerer Faktor als die CPU und ihre Taktgeschwindigkeit, denn wenn er zu knapp wird, dann wird das System richtig langsam. Es ist deshalb wichtig, dass Sie die Speichergre whrend der Messung kennen, allein schon, um das zuknftige System ausreichend dimensionieren zu knnen. Paket-Overhead Je kleiner die Paketgre wird, desto grer wird der Paket-Overhead und damit sinkt unweigerlich die Bandbreite, da das Verhltnis von Nutzdaten zu Overhead immer schlechter wird. Aus diesem Grunde werden die eigenen
365
Systeme gern mit sehr groen Paketen getestet. Gute Messungen verwenden verschiedene Paketgren, zum Beispiel 64 Byte, 100 Byte, 300 Byte, 1000 Byte und 1500 Byte, um aussagekrftige Werte zu erhalten. IPSec-Komprimierung Leider messen viele Hersteller gern ohne IPSec-Komprimierung, da sonst ihre schnen Werte dahin sind. Aber diese Funktion ist wichtig: Sie spart Bandbreite und damit Kosten. Und eine Komprimierung nach der Verschlsselung ist nicht mehr mglich. Also mssen Messungen mit IPSec-Komprimierung (IPComp) vorliegen, ansonsten sind sie unrealistisch.
11.3 Die Herstellerauswahl

Nun kommen wir zu einem etwas heiklen Thema, der Auswahl eines oder mehrerer geeigneter Hersteller. An diese Auswahl knnen Sie auf verschiedene Art und Weise herangehen: Sie knnen sich zuerst einen oder mehrere Hersteller nach bestimmten Kriterien aussuchen und ermitteln, ob diese die geeigneten Produkte in ihrem Portfolio haben. Oder Sie definieren anhand verschiedener Kriterien, die die VPN-Produkte aufweisen mssen, ein Anforderungsprofil und suchen davon ausgehend Hersteller, die passende Produkte in ihrem Programm haben. Egal auf welche Weise Sie sich an die Sache heranwagen, es werden am Ende meist mehrere in Frage kommende Hersteller brig bleiben. Jetzt stehen Sie vor der ersten wichtigen Entscheidung: Whlt man fr eine Produktfamilie einen oder mehrere, in der Regel zwei, verschiedene Hersteller aus? Dies ist nicht selten eine strategische Entscheidung, die in der Vergangenheit im betroffenen Unternehmen bereits getroffen wurde, zum Beispiel bei der Beschaffung von LAN- oder WAN-Komponenten. In diesem Fall bleibt meist keine Wahl. Im anderen Fall sollten Sie sich sehr genau berlegen, ob Sie gleiche Funktionalitten in Form von Produkten verschiedener Hersteller beziehen wollen. Das Problem sind hierbei nicht die aktuellen Produkte, sondern deren zuknftige Weiterentwicklung, die weder von der Art der neuen Features noch von deren zeitlicher Verfgbarkeit her bei verschiedenen Herstellern synchron verlaufen wird. Dies kann in der Zukunft dazu fhren, dass viele neue Funktionen der Gerte berhaupt nicht genutzt werden knnen, da sie nicht konsistent im Netzwerk verfgbar sind.
366
Die Herstellerauswahl
Also sollten Sie sich innerhalb einer bestimmten, abgegrenzten Funktionalitt, zum Beispiel dem VPN-Remote-Access, fr einen einzigen Hersteller entscheiden. Das komplette VPN, bestehend aus Remote-Access-VPN, BranchOffice-VPN, Security- und Managementsystemen kann dabei natrlich auch von verschiedenen Herstellern stammen. Nach welchen Kriterien whlt man den fr einen bestimmten VPN-Produktbereich am besten geeigneten Hersteller aus? Die im Folgenden erluterten Kriterien weisen eine Reihe gegenseitiger Abhngigkeiten auf und sind von Fall zu Fall auch von unterschiedlicher Wertigkeit. Bei einer solchen Herstellerauswahl spielt in der Praxis auch noch eine ganze Reihe anderer Faktoren eine Rolle, zum Beispiel frhere Erfahrungen mit bestimmten Produzenten, firmenpolitische Gegebenheiten oder bestehende Rahmenvertrge und vieles andere mehr, was aber hier nicht Gegenstand unserer Betrachtungen sein kann. Gre und Zukunftsaussichten Die Gre eines Unternehmens und seine voraussichtliche zuknftige Entwicklung sind ein wichtiger Faktor bei der Entscheidungsfindung. Ein VPN soll ber Jahre hinaus betrieben werden, es muss wachsen knnen, und aktuelle Entwicklungen in den dazugehrigen Technologien sollen ebenfalls Einzug finden. Dieses Ziel ist mit einer Firma, die Gefahr luft, in absehbarer Zeit vom Markt zu verschwinden oder die sich aus wirtschaftlichen oder unternehmerischen Grnden von bestimmten Unternehmensbereichen trennt, nicht zu erreichen. Sie brauchen vielmehr eine Firma, die stark genug ist, eine ausreichend lange Zeit zu existieren, um die entsprechenden Produkte herzustellen, weiterzuentwickeln und zu pflegen. Erfahrung im VPN-Umfeld Die Erfahrung im VPN-Geschft eines Herstellers ist ein weiterer wichtiger Faktor. Ist es ein Newcomer, der noch schnell auf den VPN-Zug aufspringen will, oder ist es ein Profi, der schon seit mehreren Jahren seine Erfahrungen gesammelt und die entsprechenden Mitarbeiter und Technologien hat? Aber Vorsicht, hier muss man sehr genau nachforschen, denn eine Firma, die vielleicht erst ein oder zwei Jahre existiert, kann durchaus in die Kategorie Profis fallen, wenn ihre Mitarbeiter die entsprechende jahrelange Erfahrung aus anderen Firmen eingebracht haben. Auch der umgekehrte Fall, dass sich zum Beispiel ein groes Unternehmen einen langjhrig erfahrenen VPN-Spezialisten einverleibt hat, sagt noch nichts aus, denn es kann sein, dass ein groer Teil der VPN-erfahrenen Mitarbeiter die Firma wieder verlassen hat.
367
Eingesetzte Technologien Hier ist nicht die Frage, welche Protokolle und Funktionalitten die Systeme bereitstellen mssen, das wurde ja bereits im Anforderungskatalog definiert. Interessant fr eine Entscheidung ist vielmehr, mit welcher Technologie der Hersteller dies umgesetzt hat. Da gibt es eine Reihe von Punkten zu klren: Wird ein geeignetes Betriebssystem mit einem schlanken, echtzeitfhigen Kernel eingesetzt? Erfolgt die Implementierung in Software oder in Hardware, und sind im ersteren Fall zumindest Hardwarebeschleuniger verfgbar? Ist die Software modular aufgebaut oder monolithisch? Ist die Hardware modular aufgebaut und erweiterbar? VPN-Produktportfolio Das VPN-Produktportfolio ist ein sehr guter Indikator dafr, welchen Stellenwert diese Technologie in dem betreffenden Unternehmen innehat. Ein Idealkandidat hat eine VPN-Produktpalette, die von der Clientsoftware und Small-Office-Systemen bis hin zum Hochverfgbarkeits-Remote-Access-Konzentrator und Branch-Office-Gateway alles bietet, und dies mglichst noch in verschiedenen Leistungsklassen. Bei einem solchen Unternehmen kann man getrost davon ausgehen, dass die VPN-Technologie als Kerngeschft angesehen wird. Ebenso ist die Wahrscheinlichkeit recht hoch, dass die verschiedenen Systeme untereinander interoperabel sind. Allerdings ist dies keineswegs garantiert im Gegenteil, selbst Branchengren hatten und haben bisweilen Probleme damit, ihre, unter Umstnden durch Firmenzukufe erworbenen, verschiedenen Produktfamilien zu integrieren. Also gilt auch beim Thema Kompatibilitt und Interoperabilitt der Grundsatz, zuerst nachzufragen und gegebenenfalls testen oder sich die kritischen Punkte wenigstens schriftlich garantieren lassen. Zur Verfgung stehende Service-Organisation Ein VPN ist eine unternehmenskritische Ressource. Dies bedeutet, dass Ausfallzeiten minimal sein mssen, und bedingt eine schnelle Reaktion des Herstellers, Lieferanten oder Serviceunternehmens im Fall von auftretenden Problemen. Service- und Wartungsvertrge werden oft nicht direkt mit dem Hersteller geschlossen, da viele Unternehmen ihre Produkte nicht direkt, sondern ber Distributoren, Systemhuser usw. verkaufen. Mit diesen Unternehmen schliet man in der Regel auch einen Wartungsvertrag ab. Aber auch wenn man einen entsprechenden Wartungsvertrag mit genauesten Regelungen und Vertragsstrafen abschliet, sollte man sich vorher vergewissern, ob der Vertragspartner berhaupt in der Lage ist, diesen zu erfllen. Wenn Sie sich vorher schlau machen, wie viele Servicesttzpunkte und Techniker das
368
Die Herstellerauswahl
Unternehmen besitzt, ob die Mitarbeiter qualifiziert sind und ob eine ausreichende Bevorratung mit notwendigen Ersatzteilen und Systemen erfolgt, knnen Sie sich vor bsen berraschungen schtzen. Anteil am VPN-Markt Man kann wirklich fragen, wen man will, jeder ist Marktfhrer. Es ist leider recht schwer, die Richtigkeit der vollmundigen Aussagen nachzuprfen, die zum Thema Marktanteile von den Herstellern gemacht werden. Dieser Punkt gibt auch nur begrenzt Auskunft ber die Qualitt oder Leistungsfhigkeit eines Produkts. Die jngere Vergangenheit ist leider voll von Beispielen, in denen bessere Produkte durch schlechtere vom Markt gedrngt wurden. Allerdings besteht bei einem sehr geringen, vielleicht noch sinkenden Marktanteil die Gefahr, dass das Produkt vom Markt genommen wird oder die Firma selbst Probleme bekommt, falls sie sonst keine anderen Technologien in ihrem Portfolio hat. Auch das beste Produkt ntzt nichts, wenn es nicht mehr produziert wird. Zertifizierungen des Herstellers und seiner VPN-Produkte Es gibt eine Reihe von Zertifizierungen z.B. solche zur elektrischen Gertesicherheit, Strahlungsabschirmung, Qualitt oder Systemsicherheit , die ein Gert vorweisen sollte. Im Sicherheitsbereich hat sich die IPSec-Zertifizierung der ICSA als Quasistandard durchgesetzt. Allerdings muss man hierbei sehr vorsichtig sein: Bestimmte kritische Faktoren werden von der ICSA nicht getestet oder berprft, sondern es gengt eine schriftliche Zusicherung der Hersteller. Was mit Hilfe einer Referenzimplementierung jedoch getestet wird, sind die verschiedenen Funktionalitten und Optionen von IKE und IPSec, so dass man als wichtigste Aussage der ICSA-IPSec-Zertifizierung die Interoperabilitt des Produkts ansehen kann. Systeme unterschiedlicher Hersteller sind also, eine entsprechende Konfiguration vorausgesetzt, in der Lage, ber das IPSec-Protokoll miteinander zu kommunizieren. Allerdings sollten Sie sich dabei vorher die Anmerkungen und Einschrnkungen auf der ICSA-Webseite sehr genau ansehen, um bse berraschungen zu vermeiden. Und vor allem mssen Sie unbedingt prfen, welche Version oder Release des VPN-Systems von der ICSA zertifiziert wurde, denn meist hinken die Zertifizierungen den aktuellen Versionsstnden um einige Stellen hinterher! Reaktionsgeschwindigkeit auf Markttendenzen und neue Technologien Bei der Auswahl eines geeigneten Herstellers sollten Sie ruhig einmal versuchen herausfinden, wie dieser in der Vergangenheit auf neue Mrkte und Entwicklungen reagiert hat. Die entscheidenden Punkte sind hierbei, wann der betreffende Produzent reagiert hat und ob seine Manahmen erfolgreich und richtig waren. Dieser Punkt ist deshalb so wichtig, weil man auch in der
369
Zukunft sicher sein will, dass die eingesetzten Produkte zeitnah und sinnvoll weiterentwickelt werden. Insbesondere groe Hersteller sind gelegentlich anfllig dafr, auf neue Tendenzen und Entwicklungen mit erheblicher Versptung zu reagieren, man denke nur daran, wie lange Microsoft das Thema Internet ignoriert hat. Zuknftige Plne und Visionen Hier geht es sowohl um die konkreten Plne fr die zur Auswahl stehenden Produkte als auch um die langfristige Ausrichtung des Herstellers. Insbesondere ist es interessant zu wissen, welche Bedeutung die jeweilige Kundenklasse, also Mittelstand, Grounternehmen, Service Provider usw., beim Hersteller in Zukunft haben wird. Fr einen Mittelstndler ergeben sich weniger Perspektiven bei einem Hersteller, der sich in Zukunft ganz auf den ServiceProvider- und Carrier-Markt konzentieren will, als bei einem, der sich auf den Enterprise-Bereich konzentrieren wird. Also ist neben den konkreten Produktplnen auch der Kurs interessant, den ein Unternehmen mittel- und langfristig steuert. Produktabkndigungen kommen fr die Endkunden meist aus heiterem Himmel, kein Unternehmen wird damit an die ffentlichkeit gehen, bevor es sein muss.
11.4 Die Auswahl der VPN-Komponenten

Da keine allgemein gltigen Rezepte zur Auswahl der VPN-Systeme gegeben werden knnen, sind hier, aufbauend auf die vorangegangenen Kapitel dieses Buches, die verschiedenen Teile eines Pflichtenhefts beschrieben. Sie sind ausfhrlich erlutert und knnen daher als Grundlage fr eigene Ausschreibungen oder Anforderungskataloge benutzt werden.
11.4.1
Das Beispielnetzwerk
Zu Auswahl von VPN-Gateways und VPN-Clients nehmen wir einmal ein Beispielnetzwerk mit dem Mengengerst in Tabelle 11.1 an. Es soll sich dabei um ein Internet-VPN handeln, das optional auch fr Remote-Access-Clients mit PPTP geeignet sein soll. Ansonsten, also in kleinen Auenstellen, Heimbros und Niederlassungen, wird ausschlielich das IPSec-Protokoll im Tunnelmodus eingesetzt, um auch eine Verkehrsvertraulichkeit zu gewhren. Als Option fr spezielle Anwendungen soll auch Remote Access mit L2TP einsetzbar sein. Die Benutzer sollen sich mit Tokenkarten (Response-Only Token) authentifizieren, und ein Umstieg auf die Verwendung von digitalen Zertifikaten ist in naher Zukunft geplant.
370
Die Auswahl der VPN-Komponenten
Der Service Provider untersttzt Class-of-Service und bentigt, da es sich um IPSec handelt, einen bereits dafr markierten ueren IP-Header. Im Unternehmensnetz soll weiterhin sowohl eine Ende-zu-Ende-Quality-of-Service (RSVP) als auch ein erweitertes Bandbreitenmanagement benutzt werden, um VPN-Tunneln Bandbreiten innerhalb physikalischer Verbindungen zuordnen zu knnen. Wenn man annimmt, dass niemals alle Schnittstellen mit der vollen Datenrate betrieben werden, kann man in den zentralen Systemen (VPN-Gateway und VPN-Remote-Access-Konzentrator) einen niedrigeren Wert ansetzen. In diesem Beispiel wrden zu diesem Zweck zwei E3-Schnittstellen mit 34 Mbit/s eingesetzt werden.
Anzahl Benutzer/ Standorte 2000 200 15 40 8 5 1 1
Anwender/Standort Remote Access (ISDN/Modem) Remote Access (DSL) SOHO (ISDN) SOHO (DSL) Niederlassung (128 Kbit/s) Niederlassung (1 Mbit/s) Zentrales Branch-Office-Gateway Zentraler VPN-Remote-Access
Bentigte Bandbreite 128 Mbit/s 153 Mbit/s 0,98 Mbit/s 30 Mbit/s 1 Mbit/s 10 Mbit/s 34 Mbit/s 34 Mbit/s
Tab. 11.1: Das Mengengerst des Beispielnetzwerks
Als Tunneling-Protokoll wird IPSec und optional PPTP eingesetzt. Da ein Umstieg auf Windows 2000 (Win2k) geplant ist, soll auch die Mglichkeit bereitgestellt werden, die Win2k-VPN-Clients zu terminieren, die L2TP mit IPSec im Transportmodus einsetzen. In Tabelle 11.2 bis Tabelle 11.13 finden Sie logisch gruppierte Module eines mglichen Anforderungskatalogs fr Gerte in diesem VPN. Fr andere Anwendungen gelten natrlich andere Mengengerste oder Konfigurationen. Was nicht enthalten ist, ist eine Bewertung der einzelnen Punkte, da in diesem Beispiel keine Angaben zu Applikationen, Geschftsmodell, Wachstum oder Sicherheitsstrategie enthalten sind. In einem tatschlichen Pflichtenheft sollten die Anforderungen natrlich anhand der tatschlichen Erfordernisse eines Unternehmens bewertet werden.
371
11.4.2
Allgemein
Die zentralen Systeme werden im Allgemeinen in so genannte 19"-Schrnke eingebaut und sollten aus diesem Grund ein entsprechendes Gehusema und ein geeignetes Einbaukit haben. In Niederlassungen kann eventuell auch ein 19"-Einbau mglich sein, in den kleinen Auenstellen und Heimbros bevorzugt man in der Regel kompakte Bauformen. Als Speichermedium fr die Konfigurationsdateien und Profile benutzen die greren Systeme aufgrund der Datenmengen Festplatten. Fr kleine Systeme (SOHO) reicht auch ein nicht flchtiger Halbleiterspeicher (EEPROM oder Flash-ROM) aus. Kritische Systeme, ber die viele Anwender kommunizieren und fr die meist Wartungsvertrge mit Reparaturzeiten von wenigen Stunden existieren, bentigen ein Bootmedium, mit dem eine so genannte Recovery-Routine den letzten Konfigurationsstand wieder herstellen kann. Meist sind dies Diskettenlaufwerke. Dieses Feature ist im SOHO-Bereich meist nicht erforderlich.
Zentrales VPN-RemoteNiederlassung Branch-Office- AccessGateway Konzentrator Tisch-/19"-Gert 19"-Gert EEPROM/HD Kein/Diskette 32-64 Mbyte Ja Nein 12 Festplatte Diskette 128 Mbyte Ja Ja 3+ 19"-Gert Festplatte Diskette 256 Mbyte Ja Ja 5+
Allgemein Formfaktor Speichermedium Recovery-Bootmedium Speicher erweiterbar? Beschleunigeroption Erweiterungsslots fr Interfacekarten MTBF Temperatur (Betrieb) Betriebsspannung Luftfeuchte (Betrieb)
Small Office Home Office Tischgert EEPROM Kein
Arbeitsspeicher 8-16 Mbyte Nein Nein 1
>100.000 Std. >100.000 Std. 0-40 C 100-240 VAC 10-90% 0-40 C 100-240 VAC 10-90%
>100.000 Std. 0-40 C 100-240 VAC 10-90%
>100.000 Std. 0-40 C 100-240 VAC 10-90%
Tab. 11.2: Allgemeine Anforderungen an die VPN-Komponenten
372
Der Arbeitsspeicher sollte nicht zu knapp ausfallen. Hier ist vor allem auch darauf zu achten, dass bei skalierbaren Systemen, die durch weitere Interfaces aufgerstet werden knnen, auch eine adquate Speicheraufrstung mglich ist. Ebenso sollten in Gerten, die zentral eingesetzt werden, Erweiterungspltze fr weitere Interface-Karten vorhanden sein. Systeme, die mit hohen Bandbreiten Daten verund entschlsseln mssen, sollten sowohl von ihrem Betriebssystem als auch ihren Erweiterungssteckpltzen her auf die Aufnahme von Hardwarebeschleunigern vorbereitet sein. In unserem Beispiel ist dies bei den beiden zentralen Systemen erforderlich. Bei den Umgebungsbedingungen (Temperatur, Feuchte usw.) sind die Systeme mit anderem Netzwerkequipment vergleichbar. Die MTBF (Mean Time Between Failure) sollte mindestens 100.000 Stunden betragen.
11.4.3
Leistung
Die geforderte Leistung ergibt sich aus dem Mengengerst und einer eventuell vorausgegangenen Verkehrsprofil-Analyse der Datenbertragungen. Im SOHO-Bereich sollte man mittlerweile in jedem Fall mit DSL rechnen und einen Durchsatz von mindestens 1 Mbit/s fordern. Alle Durchstze beziehen sich auf den Worst case, also die jeweils maximale Anzahl von Tunneln, sowie auf IPSec-ESP im Tunnelmodus mit Triple-DES, SHA1 und IPSecDatenkompression.
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator 3 25 bis 100 210 Mbit/s 1000 >34 Mbit/s 5000 > 34 Mbit/s
Performanceanforderungen Max. Anzahl Tunnel
Durchsatz (IPSec, 1 Mbit/s Triple-DES, SHA1, IPComp) 1 Tunnel Durchsatz (IPSec, 1 Mbit/s Triple-DES, SHA1, IPComp) max. Tunnel IKE (Shared Secret) 1 Verb./s
210 Mbit/s
>34 Mbit/s
> 34 Mbit/s
1 Verb./s
2 Verb./s
>20 Verb./s
Tab. 11.3: Die Performanceanforderungen an die verschiedenen VPN-Gateways
373
Performanceanforderungen IKE (Dig. Signatur)
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator nicht ntig 1 Verb./s < 20ms 1 Verb./s < 20ms >10 Verb./s < 20ms
Delay (IPSec-ESP, < 20ms Triple-DES, SHA1, IPComp) max. Tunnel
Tab. 11.3: Die Performanceanforderungen an die verschiedenen VPN-Gateways
Ein weiterer, vor allem fr den VPN-Remote-Access wichtiger Wert ist die Anzahl der IKE-Verbindungen, die pro Zeiteinheit aufgebaut werden knnen. Diesen Wert werden Sie in den wenigsten Datenblttern finden, da er oft sehr ernchternd wirkt! Diesen Wert mssen Sie aber, zumindest fr VPN-RemoteAccess-Konzentratoren genau wissen, denn es macht einen Unterschied, ob man pro Sekunde 1,5 oder 115 IPSec-Verbindungen aufbauen kann. Im ersten Fall wrden alle 2200 Remote-Access-User nmlich fast eine halbe Stunde bentigen, bis alle Verbindungen stehen und das bei nahezu 100% Systemlast allein fr den Verbindungsaufbau. Dieser Wert, 1,5 Sekunden, ist auch nicht aus der Luft gegriffen, sondern beruht auf den Angaben eines Datenblattes zu einem IPSec-Chipsatz. Bei der IKE-Performance spielt es auch eine magebliche Rolle, ob mit PreShared Secrets oder digitalen Signaturen authentifiziert wird, und ob auerdem noch PFS (Perfect Forwarding Secrecy) aktiviert ist. Denn davon hngt die Anzahl der verschiedenen Public-Key-Operationen ab, die fr die Schlsselerzeugung und fr die Authentifizierung ntig sind.
Authentifizierung Pre-Shared Secret Pre-Shared Secret mit PFS Digitale Signatur Digitale Signatur mit PFS Diffie-Hellman 2 4 2 4 RSA-Signatur 1 1 RSA-Verify 2 2
Tab. 11.4: Die Anzahl der bentigten Public-Key-Operationen fr die verschiedenen Formen der Authentifizierung und Schlsselerzeugung im IKE-Protokoll
Die Paketverzgerung ist ein Wert, der fr bestimmte Applikationen von entscheidender Wichtigkeit ist. Hier sollte der Anteil, den ein VPN-System zur Gesamtlaufzeit eines Datenpakets beitrgt, extrem niedrig sein. Dieser Wert hngt neben der notwendigen Verarbeitung von IPSec auch von anderen Gegebenheiten wie der Paketprioritt, der Systemauslastung und der Filterung ab alles Prozesse, die den Delay noch vergrern knnen.
374
11.4.4
Schnittstellen
Das private Interface (siehe Tabelle 11.5) ist die Schnittstelle eines VPN-Gateways, die direkt an das Intranet angeschlossen ist. Die Art und Geschwindigkeit dieses Anschlusses richtet sich zum einen nach dem bentigten Datendurchsatz und zum anderen nach der verwendeten Topologie. Allerdings hat sich die LAN-Welt mittlerweile ausschlielich fr Ethernet entschieden, so dass man VPN-Systeme mit einem Token-Ring-Interface lange suchen muss. Als Geschwindigkeiten haben sich blicherweise 100 Mbit/s oder 10/100Mbit/s-Autonegotiation durchgesetzt; im SOHO-Bereich reichen blicherweise 10 Mbit/s aus.
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Privates Interface
Ethernet 10 Mbit Ja Ethernet 10/100 Mbit Ethernet 1000 Mbit Hub (Ports) 10/100 Switch (Ports)
Ja Ja Nein Nein Nein
Ja Ja Optional Nein Nein
Ja Ja Optional Nein Nein
Ja Nein Optional Optional
Tab. 11.5: Die Schnittstellen der unterschiedlichen Systeme
Das ffentliche Interface (siehe Tabelle 11.6) kommuniziert mit dem Internet. Hier werden dann serielle Schnittstellen verwendet, wenn das System direkt an einem Netzwerk-Terminator des Carriers oder Service Providers angeschlossen ist. Falls der ISP bereits einen Router mit LAN-Interface am Standort des Kunden betreibt, kann statt dessen auch ein kostengnstiges Ethernet-Interface eingesetzt werden. Beachten Sie bitte, dass ein 100-Mbit/s-Ethernet-Interface um ein Vielfaches gnstiger ist als ein serielles E3-Interface (34 Mbit/s).
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja Ja Ja Ja Ja Ja Ja Optional Optional
ffentliches Interface
Ethernet 10 Mbit Ja Ethernet 10/100 Mbit E1-Seriell, X.21
Tab. 11.6: Die ffentlichen Interface-Typen der Gateways
375
ffentliches Interface E3-Seriell, X.21 Ethernet/PPPoE Console-Port, Terminal Console-Port, PPP
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Optional Ja Ja Optional Optional Nein Ja Ja Ja Nein Ja Ja Ja Nein Ja Ja
Tab. 11.6: Die ffentlichen Interface-Typen der Gateways
Eine serielle Konsolenschnittstelle ist unabdingbar. Hier muss in jedem Fall mit einem Terminal oder Terminalprogramm auf das System zugegriffen werden knnen. Idealerweise beherrscht das Interface auch das PPP-Protokoll, so dass auch ein grafisches Management und ein sicheres Out-of-Band-Management ber IPSec mglich sind.
11.4.5
In Internet-VPNs ist natrlich IPSec das Protokoll der Wahl. Optional knnen Sie, wenn es notwendig erscheint, auch noch PPTP einsetzen. Sie mssen darauf achten, dass bestimmte Systeme den IKE Aggressive Mode (vgl. Kapitel 8) beherrschen: 1. SOHO-VPN-Systeme bekommen in der Regel vom Service Provider eine dynamische IP-Adresse zugewiesen. Dies erfordert zwingend den IKE Aggressive Mode. 2. Daher muss das zentrale IPSec-Gateway diesen Modus, zumindest als Responder, ebenfalls untersttzen. 3. Der VPN-Remote-Access-Konzentrator terminiert IPSec-Clients, die ebenfalls im IKE Aggressive Mode betrieben werden mssen. Die Systeme in den Niederlassungen bekommen vom Service Provider feste IPAdressen zugewiesen und mssen also nur den IKE Main Mode beherrschen. Als weiteres Tunneling-Protokoll sollte man L2TP fordern, falls bestimmte Dienste wie zwangsweises Tunneling mglich sein sollen. Das L2F-Protokoll hat keine Zukunft mehr. Wenn es noch fr alte Anwendungen bentigt wird, kann man es als Feature fordern, ansonsten ist es berflssig. Davon abgesehen knnen auch viele L2TP-Implementierungen L2F terminieren.
376
TunnelingProtokolle IPSec-ESP IPSec-AH IKE Main Mode IKE Aggressive Mode IKE Pre-Shared Secret IKE Digital Signature PPTP L2TP L2F L2TP/IPSecTransport
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja Ja Ja Optional Nein Nein Nein Optional Ja Ja Ja Nein Ja Ja Nein Nein Nein Optional Ja Ja Ja Ja Ja Ja Nein Nein Nein Optional Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja
Tab. 11.7: Die verschieden Tunneling-Protokolle
11.4.6
Sicherheit
Die verschiedenen Sicherheitsfunktionen hngen teilweise von den eingesetzten Tunneling-Protokollen ab. Im Fall von IPSec mssen vom Standard her DES, MD5, SHA1 und Diffie-Hellman mit 768 Bit untersttzt werden. Im Weiteren mssen zur Datenverschlsselung ber das Internet starke Algorithmen verwendet werden: Triple-DES (168 Bit) ist in jedem Fall aus Grnden hchstmglicher Interoperabilitt zu fordern. Es ist auch gleichzeitig der vom NIST bestimmte AES-Backup-Algorithmus. Der AES ist zwar im Augenblick noch nicht offiziell verabschiedet, aber Sie sollten Rijndael bereits mit in das Pflichtenheft aufnehmen, und sei es als vom Hersteller zu garantierendes Feature einer spteren SoftwareRelease. Andere Verfahren wie Twofish, IDEA usw. knnen optional eingesetzt werden, aber natrlich nur auf allen beteiligten Systemen gleich. Fr PPTP muss ebenfalls eine starke Verschlsselung eingesetzt werden knnen, hierfr gibt es die Microsoft Point-to-Point-Encryption (MPPE), die das RC4-Protokoll mit 40 oder 128 Bit benutzt.
377
Sicherheit DES (56 Bit) Triple-DES (168 Bit) AES (Rijndael) 128 Bit IDEA, 128 Bit Twofish, 128 Bit Oakley-Group 1, 768 Bit Oakley-Group 2, 1024 Bit Oakley-Group 3, 1536 Bit RC4 128 Bit (PPTP) SHA1 MD5 SSL (Management) IPSec (Management) SSL (LDAP) X.509v3-Zertifikate
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja Ja Ja Ja sobald Stand. Optional Optional Ja Ja Optional Nein Nein Ja Ja Optional Ja Ja Ja Ja Ja Ja sobald Stand. Optional Optional Ja Ja Optional Ja Ja Ja Ja Optional Ja Ja Ja Ja
sobald Stand. sobald Stand. Optional Optional Ja Ja Optional Optional Optional Ja Ja Optional Nein Nein Ja Ja Nein Ja Nein Ja Nein
RC4 40 Bit (PPTP) Nein Nein Ja Ja Nein Ja Nein Optional
SSL-Serverzertifi- Nein kate
Tab. 11.8: Die verschiedenen Sicherheitsprotokolle
Das Management sollte ebenfalls verschlsselt werden knnen. Bei reinem Web-Management kann dies mit SSL (Secure Socket Layer) geschehen. Falls andere oder zustzliche Protokolle wie Telnet, FTP usw. eingesetzt werden sollen, empfiehlt es sich, auch fr das Management IPSec einzusetzen. Falls ein externer LDAP-Server benutzt wird, muss man hierfr auch ein sicheres Protokoll, meist das SSL-Protokoll, verwenden.
378
11.4.7
Authentifizierung
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Nein Nein Nein Nein Nein Ja Ja Nein Nein Nein Nein Nein Ja Ja Nein Nein Nein Nein Nein Ja Ja Ja Ja Ja, fr PPTP Ja, fr PPTP Ja
Authentifizierung IPSec (IKE): PreShared Secret IPSec (IKE): digitale Signatur Benutzer: Passwort Benutzer: Signatur MSCHAP Version 1 MSCHAP Version 2
Benutzer: Nein Response-Tokenkarte Benutzer: Challenge-Response-Tokenkarte RADUS-Auth. Externe LDAPAuth. PKI, PXIX-RFC PKI, Entrust* PKI, Verisign* PKI, Baltimore* PKI, man. Im/Export X.509v3-Zertifikate Autom. CRL-Update Nein
Nein
Nein
Ja
Nein Nein Nein Nein Nein Nein Nein Nein Nein
Nein Nein Ja Ja, optional Ja, optional Ja, optional Ja Ja Nein
Nein Ja Ja Ja, optional Ja, optional Ja, optional Ja Ja Ja
Ja Ja Ja Ja, optional Ja, optional Ja, optional Ja Ja Ja
Tab. 11.9: Die verschiedenen Mglichkeiten der Authentifizierung
379
Bei der Authentifizierung muss zwischen der Benutzer- und der SystemAuthentifizierung differenziert werden. Die Authentifizierung im IKE-Protokoll muss in jedem Fall, bedingt durch den Standard, eine Authentifizierung mit Pre-Shared Secrets untersttzen. Weiterhin sollte eine starke Authentifizierung durch digitale Signaturen mglich sein. Hier mssen, obwohl es damit in der Praxis noch sehr schlecht aussieht, die IETF-Standards untersttzt werden und optional noch weitere proprietre PKI-Architekturen der wichtigsten Marktfhrer in diesem Bereich (Entrust, Verisign und Baltimore). Im Fall von VPN-Gateways muss nicht unbedingt eine automatische Zertifikatverteilung erfolgen, da diese Systeme von Fachpersonal verwaltet werden und Systemzertifikate in der Regel eine relativ lange Lebensdauer haben. Da IKE keine Authentifizierung mit anderen als den im Standard (vgl. Kapitel 8) beschriebenen Verfahren untersttzt, muss eine Authentifizierung mit Token-Karten oder auch RADIUS speziell implementiert werden, um die Kommunikation unter dem Schutz einer ISAKMP-SA abwickeln zu knnen. Da fr den Remote Access optional auch PPTP eingesetzt werden soll, muss der VPN-Remote-Access-Konzentrator auch die entsprechenden Authentifizierungsverfahren (MSCHAP Version 1 und 2) untersttzen knnen.
11.4.8
Quality-of-Service und Profile
Im Unternehmensnetz soll teilweise eine Ende-zu-Ende-Quality-of-Service betrieben werden und teilweise auch bereits DiffServ als klassenbasierende QoS-Variante. Fr die flussbasierende QoS wird das RSVP-Protokoll eingesetzt. Die beteiligten Systeme, insbesondere auch die Clientsoftware, sollten dieses Protokoll untersttzen.
Quality-ofService und Profile RSVP Priorittswarteschlangen Admission Control Filterprofile Filterprofile pro User Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Nein Nein Nein Nein Nein Ja, optional Ja Ja Nein Nein Nein Ja, optional Ja Ja Nein Ja Nein Ja, optional Ja Ja Ja Ja Ja
DiffServ Marking Nein
Tab. 11.10: Quality-of-Service und Bandbreiten-Management
380
Quality-ofService und Profile Filterung, Ports Filterung, Protokolle Filterung, Adressen DHCP-Client User IP-Pool Feste IP-Adresse pro User BandbreitenManagement
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja Nein Nein Nein Nein Ja Ja Ja Nein Nein Nein Optional Ja Ja Ja Nein Nein Nein Ja Ja Ja Ja Ja Ja Ja Ja
Tab. 11.10: Quality-of-Service und Bandbreiten-Management
Mit dem Service Provider wurde ein SLA abgeschlossen, in dem auch die Umsetzung der internen Qualittsklassen auf die vom Provider untersttzen Klassen definiert wurde. Da IPSec im Tunnelmodus eingesetzt wird, sind die originalen IP-, TCP- und UDP-Header, die der DiffServ-Edge-Router zur Klassifizierung bentigt, leider bereits verschlsselt. Also mssen die Pakete zum Zeitpunkt der bergabe an den ISP bereits klassifiziert und markiert sein und das DS-Byte des inneren IP-Headers in den ueren kopiert werden. Dies tut IPSec bereits. Die Markierungen mssen also entweder bereits im Netzwerk oder, wie hier in unserem Beispiel gefordert, sptestens im VPN-Gateway klassifiziert und markiert werden. Die Gateways in der Zentrale und den Niederlassungen mssen natrlich auch die geeigneten QoS-Funktionen zum Bearbeiten der markierten Pakete bieten, vor allem verschieden priorisierte Warteschlangen. Da der Remote Access im Allgemeinen berbucht wird, muss auch eine Priorisierung des Zugangs (Call Admission Priority) mglich sein. Hier werden Benutzern oder Gruppen verschiedene Prioritten zugeteilt, die darber entscheiden, ob bei einer gewissen Auslastung des Systems noch ein Zugang erlaubt ist. Bestimmte Dienste und Protokolle knnen in guten VPN-Gateways gefiltert werden. Der Sinn und die Art der Filterung hngen von verschiedenen Kriterien und Strategien des Unternehmens ab. Allgemein ist zu fordern, dass es sowohl vorkonfigurierte Standardfilter gibt als auch eine vllige freie Definition von Filterregeln und deren Kombination zu Filtern mglich ist.
381
11.4.9
Management, Accounting, Logging und weitere Funktionen
Je nach Wunsch der Administration oder nach den Unternehmensrichtlinien ist eine grafische, eine textbasierende oder eine Kombination beider Lsungen zur Administration der VPN-Komponenten erforderlich. Die Administration, egal auf welcher Basis, muss auch gesichert mglich sein, da nicht wenige Angriffe auf Netze innerhalb eines Unternehmens gestartet werden. Ideal hierfr ist IPSec, allerdings muss in diesem Fall auch IPSec auf dem privaten Interface untersttzt werden. Falls man nur webbasiertes Management einsetzt, reicht auch eine SSL-Verschlsselung aus. Eine wichtige Funktion in verzweigten VPNs ist auch die Option, Datenverkehr direkt zwischen Tunnelendpunkten zu ermglichen. Ein bergang (Tunnelswitching) zwischen verschiedenen Tunnelmedien, z.B. IPSec auf L2TP, kann in verschiedenen Umgebungen ebenfalls Sinn machen. NAT (Network Address Translation) kann erforderlich sein, falls in den Netzen, die ber VPN-Tunnel angebunden werden, gleiche oder berschneidende IP-Bereiche vorhanden sind. Es sollten, wenn mglich, die folgenden verschiedenen NAT-Varianten zur Verfgung stehen: 1-zu-N-Nat statisches NAT (1-zu-1) dynamisches NAT (NAT-Pooling) Die verschiedenen Logging- und Accounting-Funktionen geben einen vorgefilterten Aufschluss ber bestimmte Systemereignisse: Das Security Log enthlt Informationen ber Anmeldungen, Anmeldeversuche, Eindringversuche und vermutete Angriffe sowie weitere sicherheitskritische Informationen. Das Configuration Log schreibt mit, wer an dem System welche Konfigurationsnderungen vornimmt. Dies ist ein wichtiges Feature, wenn Systeme durch verschiedene Administratoren verwaltet werden. Das System Log enthlt Informationen ber bestimmte Systemzustnde, die zur Beurteilung der Komponenten notwendig sind. Das Accounting stellt Datenstze zur Verfgung, die zur Abrechnung der VPN-Dienste benutzt werden knnen. Systeme, deren Funktion als kritisch einzustufen ist, mssen bei bestimmten Problemen, Systemzustnden oder Fehlern Meldungen (SNMP-Trap) an eine Netzwerkmanagementstation schicken, damit sofort entsprechende Manahmen eingeleitet werden knnen. Je nach Qualitt der Systeme kann man diese Traps, neben einigen Standard-Traps, frei konfigurieren. Grnde fr Traps sind zum Beispiel:
382
Stromversorgungsprobleme Hitzeprobleme Lfterausflle Eindringversuche Physischer Zugriff auf das Gert CPU-berlast Arbeitsspeicherverbrauch ber dem Limit Plattenplatz unter dem Limit Bandbreitenberlast Ausfall bestimmter Systemmodule Ein NTP (Network Time Protocol) zur netzwerkweiten Zeitsynchronisierung ist oft eine sinnvolle Sache, vor allem, wenn verschiedene Systeme mit zentralen Servern kommunzieren mssen. Funktionen fr Backup/Recovery, Standby-Protokolle (VRRP) und Lastverteilung (Loadbalancing) sind in produktiven Umgebungen wichtig, um Ausflle einzelner Systeme abzufangen. Der VPN-Remote-Access-Konzentrator muss in der Lage sein, seine auf ihn zugeschnittenen Clients zu terminieren und zu administrieren. Die komplette Konfiguration der Clients muss beim Verbindungsaufbau vom Konzentrator auf den Client bertragen werden. Die Konfiguration kann dabei auf dem VPN-Konzentrator selbst oder in einem LDAP-Directory-Server gespeichert werden.
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja
Funktion
Tunneling auf Ja dem ffentlichen Interface Tunneling auf dem privaten Interface Tunnel-Switching Nein
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Tab. 11.11: Management-, Accounting- und Logging-Funktionen
383
Funktion Paketfilterung NAT 1-zu-N NAT statisch NAT Pool Logging Accounting SNMP-Traps NTP (Network Time Protocol) Command Line Management Grafisches Management Loadbalancing Backup/Failover VRRP IPSec-ClientTerminierung
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Nein Nein Ja Nein Nein Nein Ja/Nein Ja/Nein Nein Nein Nein Nein Ja Nein Ja Ja Ja Nein Nein Ja Optional Nein Ja/Nein Ja/Nein Nein Nein Nein Nein Ja Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja/Nein Ja/Nein Ja Ja Ja Nein Ja Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja/Nein Ja/Nein Ja Ja Ja Ja
Logging (Syslog) Nein Security Logging Ja
Tab. 11.11: Management-, Accounting- und Logging-Funktionen
11.4.10 VPN-Routing
In greren VPNs kommt man mit dem statischen Routing von IPSec nicht weit, hier bentigt man spezielle Implementierungen von Routingprotollen. Diese arbeiten nur auf privaten Schnittstellen und Tunnelendpunkten und bertragen ihre Routingpakete nur im Unternehmensnetz. Auf den ffentlichen Schnittstellen drfen keine Netze publiziert oder gelernt werden. In kleinen und mittleren Umgebungen reicht meist RIP (Routing Information Protocol) aus, in greren oder stark wachsenden Netzen sollte man OSPF (Open Shortest Path First) einsetzen. OSPF muss auch mit RIP parallel betrieben und kombiniert werden knnen, um auch kleinere Lokationen, die mglicherweise kein OSPF untersttzen, integrieren zu knnen. Da IPSec-Tunnel praktisch statische Routen darstellen, mssen diese von den beiden Routing-Protokollen untersttzt werden.
384
Die Auswahl von VPN-Clientsoftware
VPN-Routing Statisch RIP-1 RIP-2 OSPF
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator Ja Ja Ja Nein Ja Ja Ja Optional Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja
Tunnel-zu-Tunnel Nein
Tab. 11.12: Die notwendigen VPN-Routing-Protokolle
11.5 Die Auswahl von VPN-Clientsoftware

Der VPN-Client ist primr ein Remote-Access-Client, der vom Service Provider bei der Einwahl jeweils andere IP-Adressen zugewiesen bekommt. Aus diesem Grund ist eine Untersttzung des IKE Aggressive Mode unabdingbar. In professionellen Umgebungen setzt man heutzutage aus Grnden eines effizienten, zentralen Managements Clients ein, die nur mit einem speziellen VPN-Remote-Access-Konzentrator betrieben werden. Diese Clients werden zentral konfiguriert, meist auf dem VPN-Konzentrator oder in einem Verzeichnisdienst; und sobald sie eine IPSec-Verbindung aufbauen, werden sie mit der aktuellen Konfiguration versorgt. Diese Konfiguration umfasst unter anderem: IPSec-Security-Einstellungen, z.B. ESP, Triple-DES, SHA1, IPComp, PFS und ARS Private (innere) IP-Adresse Primre und sekundre WINS- und DNS-Adressen Client-Sicherheitsstrategie (Filter, Bildschirmschoner, ....) Adressen von Backup-Systemen Art der Benutzerauthentifizierung Adressen oder Domainnamen, die den automatischen Start des Clients auslsen (Autoconnect) Der Anwender darf diese Parameter aus Grnden der Sicherheit natrlich nicht verndern knnen.
385
IPSec muss voll untersttzt werden. Im Allgemeinen entscheidet der RemoteAccess-VPN-Konzentrator, welcher IKE-Vorschlag (Proposal, vgl. Kapitel 8) angenommen wird. Demnach muss der Client folgende IPSec Protection Suites untersttzen: ESP mit Verschlsselung, Integrittsprfung, Authentifizierung und ARS ESP mit Verschlsselung, Integrittsprfung und Authentifizierung ESP mit Verschlsselung und ARS ESP mit Verschlsselung ESP mit Integrittsprfung, Authentifizierung und ARS ESP mit Integrittsprfung und Authentifizierung AH mit Integrittsprfung, Authentifizierung und ARS AH mit Integrittsprfung und Authentifizierung Bei der Verschlsselung sind dabei folgende verschiedene Algorithmen zu untersttzen: DES (56 Bit), vom Standard zwingend vorgeschrieben Triple-DES (168 Bit) In Zukunft AES (128 Bit) Die beiden Algorithmen zur Paket-Authentifizierung und Integrittsprfung, die im IPSec-Standard zwingend vorgeschrieben sind, sind dabei ebenfalls frei whlbar: HMAC-MD5-96 HMAC-SHA1-96 Die Authentifizierungsverfahren sind ebenfalls unterschiedlich: Pre-Shared Secret, vom Standard zwingend vorgeschrieben Digitale Signatur (X.509-Zertifikat) Token-Karten unter dem Schutz einer eigenen ISAKMP-SA Bei einer sicheren PKI ist es unabdingbar, dass die privaten Signaturschlssel tatschlich von den Benutzern verwahrt werden. Eine Speicherung auf den PC der Benutzer ist nicht ausreichend. blicherweise wird dies dadurch realisiert, dass der Benutzer eine Chipkarte erhlt, in der sein privater Schlssel gespeichert ist. Signaturen werden in der Karte erzeugt. Der private Schlssel verlsst also niemals die Karte, die der Benutzer immer mit sich fhren kann.
386
Die Auswahl von VPN-Clientsoftware
Gute Clientimplementierungen bieten Untersttzung fr Chipkarten oder Datentrger, oder sie untersttzen die Clientsoftware von PKI-Anbietern, die ihrerseits eine Chipkarten-Untersttzung bieten. Da viele Clients ber Dial-In-Verbindungen arbeiten, sollte eine gute Implementierung in der Lage sein, den Dialer des Rechners automatisch zu starten. Die PPTP-Funktionalitt kann ebenfalls im VPN-Client verankert werden, allerdings bietet das Protokoll nicht die spezielle Clientfunktionalitt. Hier kann man auch einfach die PPTP-Client-Implementierung von Microsoft (im Betriebssystem eingebaut) oder anderen Herstellern benutzen. In Tabelle 11.13 sind die Anforderungen an einen VPN-Client zusammengefasst.
Funktionalitt IKE Aggressive Mode IKE Pre-Shared-Key-Authentifizierung IKE Digital-Signature-Authentifizierung IPSec-ESP mit DES und MD5 IPSec-ESP mit DES und SHA1 IPSec-ESP mit Triple-DES und MD5 IPSec-ESP mit Triple-DES und SHA1 IPSec-ESP mit NULL-Encryption und MD5 IPSec-ESP mit NULL-Encryption und SHA1 IPSec-AH mit MD5 IPSec-AH mit SHA1 IPSec Compression IPSec Anti-Replay Service (ARS) Perfect Forwarding Secrecy (PFS) Dynamische Zuweisung der privaten, inneren IP-Adresse PPTP RC4 40 Bit RC4 128 Bit MSCHAP Version 1 MSCHAP Version 2 RADIUS-Schutz durch IPSec-SA Konfiguration durch Benutzer nicht mglich Tab. 11.13: Die Anforderungen an einen VPN-Client VPN-Client Ja Ja Ja Ja Ja Ja Ja Optional Optional Ja Ja Ja Ja Ja Ja Ja Ja, fr PPTP Ja, fr PPTP Ja, fr PPTP Ja, fr PPTP Ja Ja
387
Funktionalitt Zentrale Konfiguration des Clients bei jeder Einwahl Automatischer Backup Loadbalancing in Verbindung mit dem VPN-Gateway Integrierte Untersttzung fr Response-Token-Karten Integrierte Untersttzung fr Challenge-Response-Token-Karten Transparente Untersttzung fr PKI (PKIX-RFCs) Transparente Untersttzung fr PKI (Entrust) Transparente Untersttzung fr PKI (Verisign) Transparente Untersttzung fr PKI (Baltimore) Untersttzung von Chipkarten zur Zertifikatspeicherung Untersttzung von Datentrgern zur Zertifikatspeicherung Konfigurierbare Installation LAN-Betrieb Automatischer Start eines Dialers Paketfilterung Tab. 11.13: Die Anforderungen an einen VPN-Client
VPN-Client Ja Ja Ja Ja Ja Ja Ja, optional Ja, optional Ja, optional Ja Ja Ja Ja, fr DSL! Ja Ja
388
12
Fallstudien
In den folgenden Fallstudien werden zwei vllig unterschiedliche Anstze beleuchtet, ein VPN einzufhren: der Aufbau des VPN durch das Unternehmen selbst und die Mglichkeit, das VPN als Dienst bei einem Service Provider zu mieten. Die ersten beiden Fallstudien beschreiben zwei VPNs, die von den Kunden bzw. den damit beauftragten Systemintegratoren selbst geplant und realisiert wurden. Im dritten Beispiel bekommen Sie einen berblick ber die VPNServices eines Service Providers und einen Einblick in deren technische Realisierung.
12.1 Studie 1: Die Software AG

Die Software AG ist ein ideales Beispiel fr eine gelungene Integration von IPVPN-Technologie fr weltweiten Remote Access und Site-to-Site-Verbindungen in bereits existierende Infrastrukturen.
12.1.1
Zum Unternehmen
Die Software AG, mit Sitz in Darmstadt, ist Europas grter Anbieter von Systemsoftware. Das Unternehmen ist auf die Entwicklungen von Datenbanken und Tools fr E-Business-Lsungen spezialisiert. Die Software AG ist auf Globalisierungskurs gegangen und expandiert krftig, sowohl in Europa, Asien und Australien als auch immer strker im nordamerikanischen Markt. Das Unternehmen ist bereits seit dem vorletzten Jahr an der Deutsche Brse notiert. Aus der Expansionsstrategie des Unternehmens mit einer Vielzahl von Beteiligungen, Akquisitionen und Kooperationen und dem sich daraus ergebenden, schnellen Wachstum resultieren naturgem eine Reihe von Anforderungen an das Netzwerk, denn neue Standorte, Niederlassungen, Auenstellen und Heimbros mssen schnell und reibungslos integriert werden. Da das Kerngeschft der Software AG eine hohe Performance und Verfgbarkeit fordert, und die Produkte auf einer Vielzahl verschiedener Plattformen vermarktet werden, leiten sich daraus weitere Anforderungen an eine geeignete, flexible und migrationsfhige Netzinfrastruktur ab.
389
12 Fallstudien
12.1.2
Das Projekt
Innerhalb dieser Randbedingungen startete die SAG 1998 ein Projekt mit dem Ziel, ihren Mitarbeitern einen weltweit mobilen Zugriff auf ihr Unternehmensnetzwerk zu gewhren. Bereits damals erkannten die Projektverantwortlichen der SAG die Mglichkeiten eines Internet-VPN und evaluierten im Sinne einer zukunftssicheren und kostengnstigen Lsung die Vor- und Nachteile dieser Technologie gegenber einer Einwahl-Lsung. Es stellte sich dabei heraus, dass eine Lsung mit Standard-Einwhlsystemen bei einer weltweit operierenden Firma wie der SAG nicht mit einer VPN-Lsung konkurrieren konnte. Somit fiel die Entscheidung auf eine Remote-Access-VPNLsung. In der Folge wurden sowohl verschiedene Hersteller und deren Lsungen evaluiert als mit Verhandlungen mit Internet Service Providern ber geeignete Vertrge und Service Level Agreements gefhrt. Bei der Auswahl geeigneter VPN-Konzentratoren musste bercksichtigt werden, dass eine, allerdings immer kleiner werdende, Anzahl von Mitarbeitern noch IPX Verbindungen bentigte. Grundstzlich hat man sich bei der Software AG jedoch nach grndlicher Prfung der Sicherheitsaspekte einer VPNLsung fr IPSec als Tunneling- und Sicherheits-Protokoll entschieden. Fr die IPX Benutzer wurde fr eine gewisse bergangszeit das Point-to-Point Tunneling Protocol als einzige Alternative zu IPSec zugelassen. Die Einfhrung der VPN-Technologie im Remote-Access-Bereich der Software AG hatte auch einen Einfluss auf deren internationales Weitverkehrsnetzwerk. Denn hier stand man zunehmend vor dem Problem, dass das Frame-Relay-VPN des Unternehmens nicht beliebig ausdehnbar war, da an einigen Standorten die notwendige Infrastruktur berhaupt nicht zur Verfgung stand. Auch hier schaffte die IP-VPN-Technologie Abhilfe, denn Internet-Zugnge gibt es weltweit fast an jedem mglichen Firmenstandort. Die Zugangstechnologie unterscheidet sich war von Fall zu Fall, nicht aber die Netzwerkebene, hier werden IP-Pakete bertragen und eben diese bilden die Basis eines IP-VPNs. Also wurden an einigen Standorten entweder bereits vorhandene Router auf IPSec aufgerstet oder an anderen Standorten neue, spezielle VPN-Systeme installiert. Das VPN der Software AG ist ein hervorragendes Beispiel dafr, wie man die IP-VPN-Technologie sowohl zum Ablsen oder Umgehen des kostenintensiven Remote Access per Einwahl benutzen, als eine existierende Infrastruktur, hier ein Frame-Relay-VPN, sinnvoll damit ergnzen kann. Durch geeignete Auswahl der Systeme und Integration in die bestehende Infrastruktur, wurde der Mehrwert einer solchen Lsung hier voll ausgeschpft. Und dies bereits zu einem Zeitpunkt, an dem viele andere in Deutschland sich noch nicht einmal grundstzlich mit dem Thema VPN auseinandergesetzt hatten.
390
Studie 1: Die Software AG
12.1.3
Projektablauf und Realisierung
Die Implementierung der VPN-Lsungen erfolgte in der Software AG in verschiedenen Schritten, um eine reibungslose Migration ohne Einbrche in der Produktion zu gewhrleisten. Evaluation der einzusetzenden Hard- und Software Bevor sich die Software AG an den Aufbau ihres VPN machte, wurde eine Testinstallation durchgefhrt um die wichtigen Parameter und Funktionen des Systems zu evaluieren. In diesem Stadium wurden die ersten Erfahrungen im Umgang mit der neuen Technologie gesammelt. Man konnte sich darber hinaus entsprechende Konzepte zum Management und zur Softwareverteilung der IPSec Clientsoftware berlegen und testen, bevor das VPN produktiv eingesetzt wurde. Sukzessiver Aufbau des Remote-Access-VPN Der erste Schritt beim Aufbau des VPN war es den ersten produktiv einzusetzenden VPN-Remote-Access-Konzentrator in Betrieb zu nehmen. Es folgte kurz darauf ein zweites Gert, um sowohl eine gleichmige Lastverteilung als auch eine volle Redundanz zu haben. Der von der Software AG eingesetzte VPN-Konzentrator, ein Gert der Contivity Extranet Switch Serie der Firma Nortel Networks, erlaubt es, Gerte im Loadbalancing-Modus zu betreiben und dabei den Clients die Adressen der aktuellen Backupsysteme bei jedem Verbindungsaufbau neu zuzuweisen. Inzwischen wurde ein dritter Konzentrator installiert, um nunmehr weltweit bis zu 300 Benutzern gleichzeitigen, sicheren Zugriff auf die bentigten Dienste und Ressourcen im Netzwerk der Software AG zu gewhren. Whrend des Aufbaus des Remote-Access-VPN machten sich die Netzwerker der SAG Gedanken ber den Einsatz der IP-VPN-Technologie zum Anbinden von Standorten, an denen kein Frame Relay zur Verfgung stand. Es lag auf der Hand, sich diese Technologie, mit der man zunehmend Erfahrung gesammelt hatte, auch fr andere Zwecke zu nutze zu machen. Sukzessiver Aufbau der Branch-Office-VPN-Erweiterungen Nach der Klrung aller Randbedingungen wurde eine eine Pilotinstallation durchgefhrt mit dem Ziel, eine Aussage hinsichtlich Verfgbarkeit, Leistung und Wartung einer solchen Lsung zu machen. Dabei wurden zwei Lsungen getestet: Zum einen befanden sich in verschiedenen Standorten bereits Router, die man durch Softwareupgrades auf IPSec aufrsten wollte um die bereits gettigten Investitionen zu schtzen. Und zum anderen galt es, neue Systeme auszusuchen und zu testen, die an neu hinzu gekommenen Standorten installiert werden sollten. Die Frage, die sich hier stellte, war, neben der
391
12 Fallstudien
geforderten Kompatibilitt, auch die, ob die Performance der vorhandenen Router ausreichend sein wrde. Bei den neuen Gerten fiel die Wahl von vorn herein auf spezielle VPN-Systeme.
Bro Warschau Bro Prag Bro Chicago Bro Seattle Bro Atlanta Bro Boston
VPNGateways
VPNGateways
VPNGateways
Lokaler Provider Lokaler Provider Lokale Provider Deutschland
Lokale Provider USA
InternetBackbone
Lokale Provider USA
Lokale Provider USA
VPNKonzentrator
IPSecClients
VPNKonzentrator
Intranet Darmstadt
Intranet San Ramon
Frame Relay
Abbildung 12.1: Das weltweite VPN der Software AG
Nachdem sich alles Tests als erfolgreich erwiesen hatte, begann das Unternehmen mit der schrittweisen Erweiterung ihres Netzwerks, hin zu einem Siteto-Site-VPN das sowohl auf Frame-Relay- als auch auf IP-VPN-Technologie aufbaut.
12.2 Studie 2: Der Blutspendedienst des DRK

Diese Studie ist ein sehr gutes Beispiel sowohl fr ein Branch-Office-VPN als auch fr den Fall, dass sich ein relativ kleines VPN mit nur wenigen Standorten rechnet, sobald diese ber mehrere Lnder oder Kontinente verteilt sind.
392
Studie 2: Der Blutspendedienst des DRK
12.2.1
Zu den Unternehmen
Der Blutspendedienst des DRK Die Vielfalt der Aufgaben des DRK-Blutspendedienstes reicht von der Motivation der Bevlkerung, freiwillig und unentgeltlich Blut zu spenden, ber die Blutentnahme beim Spender und das Untersuchen und Aufbereiten des Spenderblutes bis hin zur Fort- und Weiterbildung von rzten und rztlichem Hilfspersonal im Transfusionswesen; hinzu kommt die Forschung auf dem Gebiet der Transfusionsmedizin. Dabei hat sich die freiwillige und unentgeltliche Blutspende weltweit vom Roten Kreuz, der Weltgesundheitsorganisation und anderen freien und gemeinntzigen sowie staatlichen Trgern propagiert als wirksamstes System zur Sicherstellung der Versorgung mit Blut erwiesen. Zwlf berregionale DRK-eigene Blutspendedienste mit 38 Instituten sorgen fr eine flchendeckende Versorgung mit Blut und Blutbestandteilen. 170 mobile Entnahmeteams fhren jhrlich ca. 40.000 Blutspendetermine durch, zu denen insgesamt etwa 3,8 Millionen Blutspender erscheinen. Rund 3.800 qualifizierte hauptberufliche Mitarbeiter kmmern sich als rzte, Chemiker, Biologen, Apotheker, Schwestern, Laborkrfte und Angestellte um eine fachgerechte Blutentnahme, um Transport und Lagerung und schlielich um die Bereitstellung von Blutprparaten in der Klinik. Mehr als 200.000 ehrenamtliche Helferinnen und Helfer der Kreis- und Ortsverbnde sowie -Bereitschaften setzen sich alljhrlich fr die Blutspenderwerbung, die Vorbereitung und Durchfhrung der Blutspendetermine in ihrer Freizeit ein. Etwa zwei Millionen Bundesbrger spenden zum Teil mehrfach pro Jahr unentgeltlich Blut. Zahlreiche Schulen, Betriebe, militrische Einheiten, Gemeindeverwaltungen, ffentliche und private Einrichtungen und die Medien untersttzen die Aufgaben des Blutspendedienstes durch die kostenlose Bereitstellung von Rumlichkeiten und die Verbreitung von Spendenaufrufen. Das Deutsche Rote Kreuz stellt rund 80% Prozent der Blutversorgung in der Bundesrepublik Deutschland sicher und verfgt ber entsprechende Vorrte fr Notflle und Katastrophen. ASAP-COM Als Dienstleistungsunternehmen fr Informations- und Telekommunikationssysteme mit Sitz in Heilbronn und Niederlassungen in Kln und Hamburg bietet die ASAP-COM GmbH seit 1999 Beratung, Planung und Service fr den Betrieb von Netzwerkstrukturen an. Das Unternehmen hat sich dabei auf die Schwerpunkte LAN, WAN, VPN, Voice over IP und Security spezialisiert. Fr andere Bereiche, z.B. PC-Technik, arbeitet ASAP-COM mit anderen, festen Partnern zusammen.
393
12 Fallstudien
Die Mitarbeiter der jungen Firma sind Netzwerkprofis, die langjhrige Erfahrung aus verschiedenen Unternehmen der IT-Branche mitbringen. Die Projekte, die ASAP-COM fr seine Kunden durchfhrt, werden meist in enger Zusammenarbeit mit den Weltmarktfhrern im IT-Bereich, wie Cisco Systems, Lucent Technologies, Hewlett-Packard und Nortel Networks, realisiert, von denen das Unternehmen und seine Mitarbeiter auch entsprechend zertifiziert sind.
12.2.2
Das Projekt
Der Anlass fr dieses Projekt war die Anforderung, dass Software-Entwickler in Indien auf Rechnersystemen in Deutschland Software fr AS/400-Applikationen entwickeln sollten. Der Blutspendedienst des DRK beauftragte die Firma ASAP-COM mit der Ausarbeitung eines Netz-Konzepts inklusive Service und Wartung, der Netzaufnahme vor Ort, einer Teststellung mit Protokollierung der Messergebnisse und einer Angebotserstellung. Aufgrund der ansonsten hohen Kosten und technischen Probleme mit Festverbindungen, wurde schnell klar, dass insbesondere der Einsatz der VPNTechnologie zu prfen war. Aus den Anforderungen ergab sich, dass eine Verschlsselung mit 56-Bit-Schlsseln ausreichend ist. Ebenso wurden keine Applikationen erkannt, die empfindlich auf Verzgerungen oder Jitter reagieren oder ein spezielles Bandbreitenmanagement bentigen. Nach einer Analyse des VPN-Marktes, wobei Produkte mit den notwendigen Features und einem guten Preis-Leistungs-Verhltnis ausgesucht wurden, wurde ein VPN-Konzept erstellt. Da, um hier zuknftig auch noch weitere Standorte anbinden zu knnen, in dem deutschen Standort (Breitscheid) auch auf die Skalierbarkeit groer Wert gelegt wurde, hat ASAP-COM hier ein greres System installiert, das bei 1000 parallelen IPSec-Tunneln und TripleDES-Verschlsselung eine Bandbreite von ber 30 Mbit/s ohne Hardwarebeschleuniger aufweist. Der vorgeschlagene Nortel Networks Contivity Extranet Switch 2600, der maximal 1000 Tunnel terminieren kann, lsst sich mit weiteren Schnittstellenkarten und Hardwarebeschleunigern aufrsten und in Zukunft auch fr VPN-Remote-Access einsetzen. Im indischen Technologie-Park Trivandrum (Kerala), in dem die Programmierer der Softwarefirma IVL arbeiten, wurde ein kleineres VPN-Gateway installiert. Hier ist nur eine Bandbreite von 64 kBit/s gefordert, die bei Bedarf auf 128 Kbit/s erweiterbar sein soll. Das fr diesen Standort empfohlene System, ein Nortel Networks Instant Internet 100, kann problemlos die erforderliche Verschlsselungsleistung bereitstellen.
394
12.2.3
Projektablauf und Realisierung
Nachdem das Konzept stand, wurde es in der Praxis zuerst auf seine Tauglichkeit getestet, bevor mit der Installation und Inbetriebnahme begonnen wurde. Zu diesem Zweck wurde eine Pilotinstallation aufgebaut, um die VPN-Lsung zwischen der Zentrale von ASAP-COM in Heilbronn und IVL-India in Trivandrum unter realen Bedingungen zu testen und entsprechende Messungen zur Ermittlung der Bandbreiten und Verzgerungszeiten durchzufhren. Die Tests sollten neben der grundstzlichen Funktion auch verschiedene Anbindungsoptionen miteinander vergleichen: 1. ILV-India benutzt zusammen mit anderen Firmen im Technopark einen ISP, der ber eine 64-kBit/s-Festverbindung angeschlossen ist. 2. ILV-India benutzt einen exklusiven Internetanschluss fr die RemoteApplikationen mit 64 Kbit/s. 3. ILV-India benutzt einen eigenen 64-Kbit/s-Internetanschluss. Diese drei Szenarien hatte ASAP-COM vom 4. bis 6. August 2000 in Heilbronn und Trivandrum in Zusammenarbeit mit den lokalen Internet Service Providern in Indien getestet, und es wurden entsprechende Messprotokolle erstellt. Gemessen und beurteilt wurden im Einzelnen: Die Paketumlaufzeit (Indien-Deutschland-Indien) Die mittlere Bandbreite bei Dateitransfers unkomprimierter Dateien Der subjektive Eindruck von der Benutzbarkeit der Terminalemulation Im ersten Fall waren die Ergebnisse erwartungsgem schwach, sowohl bei den Paketlaufzeiten als auch bei der mittleren Bandbreite. In Trivandrum mit Terminalemulationen in auf einem System in Deutschland zu arbeiten war praktisch nicht mglich.
Szenario 1 Paketumlaufzeit Mittlere Bandbreite Subjektiver Eindruck beim Einsatz der Terminalemulation 5000 ms 2 Kbyte/s Mangelhaft Szenario 2 500 ms 6,2 Kbyte/s Gut Szenario 3 2000 ms 4 Kbyte/s Ausreichend
Tab. 12.1: Der Vergleich der drei getesteten Einsatzszenarien
395
12 Fallstudien
Der zweite Fall, also ein ausschlielicher Test des VPN fr den Zugriff auf die Rechner in Deutschland, wurde geprft, indem direkt beim indischen Internet Service Provider Satyam Infoway Ltd. die Systeme installiert und getestet wurden. Die Ergebnisse waren erwartungsgem gut, vor allem die Paketlaufzeit. Im dritten Szenario waren die Werte und der subjektive Eindruck beim Arbeiten mit der Terminalemulation ebenfalls insgesamt befriedigend.
InternetBackbone
ISP Deutschland
ISP Indien
Router
Router
DMZ
IPSec Gateway Firewall DMZ
Firewall
IPSec Gateway
LAN Breitscheid, Token Ring
LAN IVL-India Ethernet
AS/400
NT Workstations mit AS/400 Emulation
Intranet Breitscheid
Intranet IVL-India
Abbildung 12.2: Das VPN des DRK-Blutspendedienstes nach der ersten Projektphase
Nachdem die Tests insgesamt aus technischer Sicht erfolgreich verlaufen waren, empfahl ASAP-COM die Realisierung des VPN ber eine direkte Anbindung von IVL-India ber den ISP Satyam Infoway. Fr eine kurzfristige Anbindung kann auch die vorhandene Infrastruktur bergangsweise eingesetzt werden. Das VPN wurde gem Abbildung 12.2 realisiert. Im Standort Breitscheid in Deutschland wurde das zentrale VPN-Gateway mit seinem ffentlichen Interface in der DMZ hinter der Firewall installiert. Das private Interface liegt im LAN Breitscheid. Analog dazu wurde Nortels Instant Internet in Trivandrum ebenfalls zwischen der DMZ und dem Intranet angeordnet. Zur Internetanbindung wurden die bereits vorhandenen Router benutzt. Die Installation wurde am 30. August 2000 produktiv in Betrieb genommen.
396
Aufgrund der guten Erfahrungen wurde die VPN-Thematik weiter verfolgt, und im Dezember 2000 wurden zwei weitere Standorte in Deutschland, Hagen und Mnster, in das VPN integriert. Die Zugangsgeschwindigkeiten der beiden neuen Niederlassungen betragen 1 Mbit/s, und der Breitscheider Router ist mit einer E1-Verbindung (2 Mbit/s) angebunden. Der komplette IPVerkehr geht nun ber das VPN. Parallel zu dem VPN wird aus technischen Grnden noch ein Frame-RelayNetz betrieben, ber das der komplette SNA-Verkehr (SNA over Frame Relay) abgewickelt wird.
Weitere Standorte IPSecClient

In Planung
LAN IVL-India Ethernet
IPSec Gateway Router
In Planung
InternetBackbone
ISP Deutschland
ISP Indien
1 Mbit/s Router IPSec Gateway
2 Mbit/s
1 Mbit/s Router IPSec Gateway
Router IPSec Gateway Firewall
Firewall
Firewall
LAN Mnster, Ethernet
LAN Breitscheid, Token Ring
LAN Mnster, Hagen
Abbildung 12.3: In der zweiten Phase wurden weitere Standorte in Deutschland angebunden; weitere, ebenso wie der VPN-Remote-Access, sind in Planung.
Fr weitere Labors und Einzelplatzsysteme sind je nach Einsatz weitere kleine VPN-Gateways oder IPSec-Clients geplant, die auf den dafr ausreichend dimensionierten Gateways terminiert werden knnen. Die Systeme knnen pro Gert bis zu 1000 Tunnel terminieren und erreichen mit einer Beschleunigerkarte ber 60 Mbit/s bei maximaler Verschlsselungsstrke. Fr das komplette Netzwerk gibt es in Breitscheid nur einen einzigen bergang in das Internet, den alle Benutzer in den verschiedenen Standorten benutzen. Somit wird eine konsistente Sicherheitsstrategie ermglicht.
397
12 Fallstudien
12.3 VPN-Dienste von Service Providern

Eine grundstzliche Alternative beim Aufbau eines VPN besteht darin, dies nicht in Eigenregie zu tun, sondern den VPN-Dienst eines Service Providers zu nutzen. Solche Dienste knnen in ihrer Struktur und dem Umfang des Angebots von Provider zu Provider recht unterschiedlich sein und reichen vom einfachen Internetzugang bis zum vollstndigen Outsourcing des VPN. Generell kann der Kunde zwischen drei verschiedenen Alternativen whlen, die je nach Provider noch verschiedene Zwischenstufen haben knnen: 1. Der Kunde bekommt vom Service Provider nur einen Internetzugang bereitgestellt und schliet ein fr seine VPN-Anforderungen ausreichendes Service Level Agreement (SLA) ab. 2. Der Kunde bekommt vom Service Provider ein Paket mit Internetzugang, VPN-Systemen und ein SLA inklusive Wartung und Betrieb aller Komponenten. Der Benutzer verwaltet jedoch den privaten Teil des VPN-Gateways, seine Benutzer und Profile selbst, ohne dass der Service Provider darauf Zugriff hat. 3. Der Kunde kauft einen Vollservice inklusive Benutzermanagement und aller Leistungen. Der Provider ist fr den kompletten VPN-Betrieb verantwortlich. Die Abwgung, welches Modell am gnstigsten ist, ist immer ein Kompromiss zwischen einer Reihe von Vor- und Nachteilen und richtet sich nicht selten auch nach strategischen Vorgaben des Unternehmens, inwieweit bestimmte Funktionen durch externe Dienstleister wahrgenommen werden sollen oder drfen.
Vorteile fr den Kunden Alternative 1 Keine langfristige Bindung an den Provider, ein Wechsel oder der Einsatz mehrerer Provider ist jederzeit mglich. Volle Kontrolle ber das VPN. Reduzierung der Kosten gegenber Alternative 1, leicht verminderter Personalaufwand, keine Investitionen. Niedrige Kosten, fast kein Personalaufwand mehr; keine Investitionen. Nachteile fr den Kunden Relativ hohe Kosten durch den erforderlichen Personalaufwand und die notwendigen Investitionen. Lngerfristige Bindung an einen Provider ntig. Meist keine Mitsprachemglichkeit bei der Auswahl der eingesetzten Technologie. Sehr starke Abhngigkeit vom Provider und keine eigene Kontrolle ber das VPN.
Alternative 2
Alternative 3
Tab. 12.2: Die wichtigsten Vor- und Nachteile der verschiedenen Alternativen
398
Studie 3: Die VIAG Interkom
Im folgenden Abschnitt sind, stellvertretend fr diese Art von Service-Provider-Diensten und ohne jede Wertung, exemplarisch die VPN-Services der VIAG Interkom aufgefhrt. Anhand dieser Aufstellung knnen Sie sowohl die verschiedenen Mglichkeiten abschtzen, die solche Dienste bieten, als auch sehen, wie die verschiedenen in diesem Buch besprochenen VPN- und Sicherheitstechnologien dafr eingesetzt werden. Um dem Entscheider und dem Netzwerkverwalter einen berblick ber die Mglichkeiten zu geben, die er mit den VPN-Diensten hat, sind diese recht detailliert dargestellt, damit Sie vor allem einen direkten Vergleich zu der Alternative haben, Ihr VPN ohne Mitwirkung eines Service Providers (Internetzugriff natrlich ausgenommen) aufzubauen und zu betreiben. Der technisch Interessierte bekommt zustzlich einen Einblick in die Interna eines ISP und in den Einsatz der in der Regel nur dort verwendeten Provider-Enterprise- und Intra-Provider-Tunneling-Modelle unter Verwendung von L2TP und BayDVS. Andere Service Provider betreiben selbstverstndlich andere Infrastrukturen und bieten auch andere oder unterschiedlich gebndelte Dienstleistungspakete an. Hier muss natrlich im Einzelfall geprft werden, wie diese in das geplante VPN passen. Auf der anderen Seite ist dieser Markt auch einer sehr groen Dynamik unterworfen, und es werden laufend neue Dienste angeboten. Die sich ndernde Infrastruktur, insbesondere die in Zukunft fast flchendeckende Verfgbarkeit des High-Speed-Internet-Zugriffs ber DSL oder andere Breitbandtechniken, bringt auch vllig neue Dienste und Unternehmen wie z.B. die Application Service Provider (ASPs) hervor, die vielleicht in ein VPN integriert werden sollen.
12.4 Studie 3: Die VIAG Interkom

Als Beispiel fr verschiedene komplette, durch Provider angebotene VPNLsungen, bietet sich die VIAG Interkom mit ihren verschiedenen VPNDiensten an, an denen sich der Einsatz der verschiedenen Tunneling-Technologien gut demonstrieren lsst. Das Unternehmen hat in Deutschland schon eine sehr lange Erfahrung im VPN-Bereich, was man unter anderem auch an der Palette der angebotenen Services ermessen kann. Um zu sehen, wie sich die Endkunden die angebotenen Dienste zunutze machen knnen, gebe ich Ihnen zuerst mal einen berblick drber was alles angeboten wird, um dann einige Beispiele fr eine sinnvolle Nutzung und die eingesetzte VPN-Technik zu beschreiben.
12.4.1
Zum Unternehmen
VIAG Interkom (VI) bietet Telekommunikationsdienste in Deutschland an. Als Tochterunternehmen von British Telecom (BT) ist VI mit den drei Kernbereichen Mobile, Fixed Voice und Fixed Data auf dem deutschen Markt vertre-
399
12 Fallstudien
ten. VIAG Interkom betreibt hierzu eigene Mobil- Sprach- und Datennetze, welche dem neusten Stand der Technik entsprechen und stndig weiter ausgebaut werden; eine UTMS-Lizenz wurde ebenfalls ersteigert. An Datennetzen betreibt VI eigene Frame-Relay-, ATM-, Internet- und DialAccess-IP-Strukturen. Durch die Verbindung mit British Telecom ergeben sich hierbei viele Synergieeffekte aufgrund der weltweiten Nutzungsmglichkeit der BT- und Concert-Datennetze.
12.4.2
Der IP-VPN-Dienst
Das Produkt IP-VPN der VIAG Interkom wird seit Anfang 2000 erfolgreich am deutschen Markt angeboten. Es beinhaltet die Mglichkeit Daten ber das Internet mittels der Tunneling-Protokolle BayDVS (Bay Dial-In VPN-Service) L2TP (Layer 2 Tunneling Protocol) IPSec (IP Security) zu bertragen, wobei lediglich IPSec als sicheres bertragungsprotokoll angesehen und vermarktet wird. Mit diesen Protokollen und den darauf aufbauenden Diensten knnen praktisch alle Spielarten heutiger IP-VPNs realisiert werden. IP Security IPSec wird von VIAG Interkom wahlweise mit DES-Verschlsselung (56 Bit Schlssellnge) oder Triple-DES-Verschlsselung (168 Bit Schlssellnge) angeboten und deckt damit auch hohe Anforderungen hinsichtlich Vertraulichkeit, Authenzitt und Integritt der bertragenen Daten ab. Internationale Verbindungen Durch die Nhe zur British Telecom ist es mglich, den IP-VPN-Dienst international auszurichten. Dies umfasst bereits heute den Anschluss von im Ausland befindlichen Standorten durch Festverbindungen. VI betreibt in Deutschland einen eigenen Internet-Backbone, der ber entsprechende Peering-Punkte zu anderen Netzbetreibern verfgt und stndig erweitert und ausgebaut wird, um den aktuellen Bedrfnissen gerecht zu werden. Somit kann auch ber andere Provider oder einen Anschluss an das Frame-RelayNetz der VIAG Interkom Zugang ihrem IP-Backbone erfolgen. Authentifizierung der Einwhlverbindungen Die Einwhlverbindungen in die POPs der VIAG Interkom werden mit Hilfe des PPP-Protokolls authentifiziert.
400
Hierzu verwendet VI intern das RADIUS-Protokoll. Hierbei wird die Anfrage zuerst zu einem so genannten Frontend-RADIUS-Server geleitet, der den Authentication Request in unterschiedliche Dienste einteilt und ihn anschlieend an den VI-VPN-Radius weiterleitet. Dieser ist nun fr die Authentifizierung der Benutzer und gegebenenfalls die Zuweisung von Tunneling-Attributen fr L2TP oder BayDVS zustndig. Auf Wunsch des Kunden kann dieser einen eigenen RADIUS Service zur User-Authentisierung verwenden. In diesem Fall wird die Anfrage zur Benutzer-Authentifizierung an den RADIUS-Server des Kunden durch einen Tunnel ins Kundennetz geleitet. Somit kann der Kunde seine Benutzer vollstndig selbst verwalten. IPSec Authentifizierung Zur Authentifizierung der beiden Gegenstellen einer IPSec-Sicherheitsassoziation verwendet VI derzeit das Pre-Shared-Key-Verfahren. Fr den Anwender bedeutet dies im Fall eines Remote-Access-VPNs eine Authentifizierung mit User-ID und Passwort. Optional ist auch eine Authentifizierung mit Tokenkarten mglich, die eingesetzte Clientsoftware untersttzt diese Verfahren. Zugnge VIAG Interkom bietet fr ihren IP-VPN-Dienst eine Reihe verschiedener Zugnge an, die von der Art und der bentigten Bandbreite abhngen: L2TP Dial Access (ISDN und Analog) fr Client PCs und Dial-in-Router IPSec Dial Access (ISDN und Analog) fr Client PCs und Dial-in-Router Leased-Line-Anschluss ber Internet von 64 kBit/s bis 34 Mbit/s (E3) Leased-Line-Anschluss ber Frame Relay mit bis zu 512 kBit/s Hardware Um fr die Hardwarewnsche der Kunden offen zu sein, werden bei VIAG Interkom Systeme der beiden Marktfhrer im Router- und VPN-Bereich, den Firmen Nortel Networks und Cisco Systems, angeboten. Dies umfasst das sogenannte CPE-Equipment (CPE, Customer Premise Equipment, Systeme, die beim Endkunden installiert, aber vom Provider betrieben werden), also die IPSec-Clientsoftware, kleinere Router fr Fest- oder Whlverbindungen und die VPN-Gateways. Die von VIAG Interkom eingesetzten VPN-Gateways sind sehr gut skalierbar und untersttzten je nach eingesetztem Modell bis zu 5000 parallele Tunnel
401
12 Fallstudien
pro Gert. Sie erreichen dabei Durchsatzraten von ber 70 Mbit/s mit TripleDES Verschlsselung. Installation und Inbetriebnahme Wird bei einem Kunden neues Equipment installiert, so greift VIAG Interkom auf die Dienste externer IT-Dienstleister zurck. Diese Service-Unternehmen sind fr den Aufbau und den Anschluss der Gerte in den Kundenstandorten zustndig. Des weiteren stellen sie eine gesicherte IPSec-Verbindung zu Customer Service Center der VI her. Von dort aus erfolgt dann zentral die weitere Systemkonfiguration und Einrichtung der Sicherheitsdienste sowie die endgltige, produktive Inbetriebnahme. Redundanz Da viele Kunden ein hoch verfgbares Netzwerkdesign haben mchten, sind alle Netzelemente der VIAG Interkom redundant ausgelegt, oder knnen auf Wunsch des Kunden fr ihn redundant eingerichtet werden. Eine Redundanz ist im Sprachnetz, dem NAS und dem VI-Backbone generell vorhanden. Um den Ausfall einer Festverbindung (Leased Line) oder eines VPN-Gateways beim Kunden entgegenzuwirken, besteht die Mglichkeit auch diese Systeme doppelt auszulegen. Die zweifach vorhandenen Systeme knnen entweder im so genannten Hot-Standby-Modus (sofortige Funktionsbernahme durch ein im Wartezustand befindliches System), oder auf Wunsch auch im so genannten Load-Sharing-Modus verwendet werden, bei dem sich beide Systeme im Normalbetrieb die Netzlast gleichmig untereinander aufteilen. Monitoring VIAG Interkom bietet seinen Kunden die Mglichkeit, den VPN-Dienst mit unterschiedlichen Optionen zu kaufen. Unterteilt werden diese Dienste in: Bundled Service Semibundled Service Unbundled Service Die erste Variante, der Bundled Service, erfreut sich bei den Kunden einer hohen Beliebtheit und wird derzeit fast ausschlielich verkauft. Bundled Service bedeutet, dass die gesamte Infrastruktur (CPE, VI-Backbone, VPN-Gateways usw.) seitens VIAG Interkom zur Verfgung gestellt, konfiguriert und berwacht wird. Der Kunde muss sich hierbei, auer dem Einrichten seiner eventuell vorhandenen PC-Clients und seiner Benutzer um nichts kmmern. Bei Erweiterungen seines Netzes oder bei eventuell auftretenden Problemen hat der Kunde nur noch einzigen Ansprechpartner.
402
Beim Semibundled Service ist all dies ebenso, jedoch betreibt der Kunde in der Regel sein eigenes CPE Equipment, fr das er dann allerdings auch selbst verantwortlich ist. Auch die Konfiguration dieser Gerte erfolgt durch den Kunden selbst, allerdings nach technischen Anweisungen von VI. Bei dem Unbundled Service nutzt der Kunde lediglich die Internet-Accessund Internet-Struktur der VIAG Interkom. Berechnet werden die Dienste mit einer monatlichen Pauschale fr Bereitstellung der Gerte, dem so genannten Monitoring, also der berwachung des Netzverkehrs hinsichtlich Performance und Fehlern, sowie einem volumenbasierten Anteil. Verfgbarkeit Der VIAG Interkom IP-VPN Dienst wartet mit einer Verfgbarkeit von 99,97% auf, was einer maximalen Ausfallzeit von ein klein wenig mehr als 2,5 Stunden pro Jahr entspricht. Dies gilt natrlich nur fr Verkehr innerhalb der Infrastruktur von VI, da nur hier die entsprechenden Systeme eingesetzt und geeignete Manahmen getroffen werden knnen. Sollte dennoch in den Standorten der Kunden an einem VPN- oder AccessSystem ein Hardwaredefekt derart auftreten, dass es ausgetauscht werden muss, dann wird das defekte Gert durch einen IT-Dienstleister, der ber die geeignete Logistik verfgt, innerhalb kurzer Zeit ausgetauscht. Das BCCC (Business Customer Care Center) der VIAG Interkom, das zentral die letzte gltige Konfiguration aller System vorrtig hlt, spielt nach dem Austausch des defekten Gerts die letzte Sicherung des betroffen Systems wieder ein. Anschlussvarianten Um die Auenstellen von Firmen anzuschlieen, gibt es die Mglichkeit diese per Whl- oder Festverbindung anzuschlieen. In beiden Fllen wird man, da sich in der Auenstelle in der Regel ein kleineres, privates Netz mit nicht registrierten oder sich berschneidenden Adressen verbirgt, NAT (Network Address Translation) verwenden. Die Anschlussbandbreiten fangen hierbei bei einer 64kBit/s Whlverbindung (ISDN) an, und enden bei einem 34 Mbit/s (E3) Anschlu. Des weiteren besteht die Mglichkeit, sich als Auendienstmitarbeiter per ISDN oder analoger Einwahl in das Firmennetz einzuwhlen. Da die meisten Kunden neben dem IP-VPN-Dienst auch noch den Dienst IPTransport, also den klassischen Internetzugang kaufen, erfolgt der Anschluss an das Firmennetz ber zwei Verbindungen. Das VPN-Gateway bernimmt den Zugang von und zu den Firmenauenstellen, den Auendienstmitarbeitern und den Benutzern an Heimarbeitspltzen. Als zweites gibt es eine Verbindung vom Internet in das Firmennetz, ber die ein Unternehmen mit der Auenwelt kommuniziert. Die Aufteilung der beiden Leitungen wird durch einen Gateway-Router durchgefhrt, der auf seiner anderen Seite die Verbindung zum VI-Netz aufrecht erhlt.
403
12 Fallstudien
Selbstverstndlich besteht auch die Mglichkeit, zwei per Festverbindung mit dem VI-Backbone verbundene, Firmennetze ber VPN-Gateways durch einem IPSec-Tunnel zu verbinden. Die hierbei mglichen Datenraten beginnen bei 64 kBit/s und enden bei einer E3-Verbindung (34 Mbit/s).
12.4.3
Infrastruktur
VIAG Interkom betreibt sowohl eigene Fest- als auch Mobilfunknetze. Den Internet-Backbone, der in Deutschland betrieben wird, sehen Sie in der Abbildung 12.4 skizziert. Alle Knoten sind mindestens zweifach redundant verbunden. Die stndig angepassten Geschwindigkeiten betragen dabei auf den Links 155 Mbit/s, auf einigen wenigen 45 Mbit/s. Natrlich gibt es auch bergnge zu anderen Providern und NAPs (Network Access Point) in den USA, Europa und Deutschland. In Frankfurt (DECIX) und Mnchen (INXS) sind die deutschen Internetbergnge installiert.
Hamburg Bremen Berlin Hannover Essen
Level 3
Dsseldorf
Frankfurt DECIX
Leipzig
AT&T New York
Kln
LINX London Concert
Frankfurt
Mannheim Nrnberg Karlsruhe

155 Mbit/s 45 Mbit/s
Interconnect
Stuttgart
Mnchen INXS
Mnchen
Abbildung 12.4: Der deutsche Internet Backbone der VIAG Interkom, Stand 12/2000
404
12.4.4
Remote-Access-VPN
Je nachdem was dem Kunden vorschwebt, kann er aus einer Reihe verschiedener Remote-Access-VPN-Lsungen whlen, oder diese auch miteinander kombinieren. So bietet VIAG Interkom folgende drei verschiedenen Technologien an: Bay-DVS Bay-DVS ist eine herstellerspezifische Kombination von Mobile IP, Generic Routing Encapsulation (GRE) und RADIUS der Firma Nortel Networks. Der Name Bay-DVS (Bay Dial In VPN Service) stammt noch von dem IP-Spezialisten Bay Networks, der von Nortel Networks bernommen wurde. Das Protokoll ist ein Layer-3-Tunneling-Protokoll, dass sowohl IP als auch IPX tunneln kann. Es erfreut sich vor allem bei Service Providern und Carriern groer Beliebtheit. Der groe Vorteil fr den Kunden besteht darin, dass er keinerlei spezielle VPN-Hard- oder Software kaufen, mieten oder installieren muss. In Abbildung 12.5 sehen Sie wie dieses Protokoll arbeitet. Die Remote-Access-ClientSysteme bauen mit einem Standard-PPP-Dialer eine Whlverbindung zu einem POP (Point of Presence) der VIAG Interkom auf. Dabei benutzen sie eine zweiteilige User-ID mit einem sogenannten Domain-Suffix, z.B. mlipp@nortelnetworks.com. Aufgrund des Suffix erkennt der Remote-Access-Konzentrator dass er einen Tunnel zum Bay-DVS-Gateway aufbauen muss. In diesem Gateway wird der Tunnel auf einen Frame-Relay-PVC gemappt, der zum Access-Router des Kunden fhrt. Die Authentifizierung der Benutzer erfolgt im Kundennetzwerk mit einem RADIUS-Server, der RADIUS-Client residiert im Bay-DVS-Gateway. L2TP Dies ist beim L2TP-Verfahren nicht so, hier mssen der Access-Router oder das VPN-Gateway beim Kunden fr dieses Protokoll ausgelegt sein. Es muss also mindestens die entsprechende Software, der L2TP Network Server (LNS), installiert werden. Auf den Einwhl-Clients braucht aber auch hier keine besondere Software installiert zu werden. Das Tunneling erfolgt, wie Sie in Abbildung 12.5 sehen knnen, analog zu Bay-DVS, allerdings wird der L2TP-Tunnel bis in das Kundennetzwerk gefhrt. Die Authentifizierung der Benutzer erfolgt meist im Kundennetzwerk mit einem RADIUS-Server.
405
12 Fallstudien
L2TPLNS
KundenIntranet
VIAG InterkomNetz
Bay-DVS Gateway
KundenFrame Intranet Relay
VPNGateway
L2TPTunnel
Bay-DVS-Tunnel
ISDN PSTN
PPPClient
VIAG Interkom Business Customer Care Center (BCCC)
POPs
PPPClient
Control Tunnel
Abbildung 12.5: Die Layer-2- und Layer-3-VPN-Dienste der VIAG Interkom mit L2TP und Bay-DVS
IPSec Das IPSec-Protokoll eignet sich auch sehr gut fr den Remote-Access. Hier kommt der Anwender, im Gegensatz zu L2TP und Bay-DVS, in den Genuss einer sehr viel hheren Sicherheit. Hier sind jedoch sowohl auf den RemoteAccess-Clients als auch auf dem VPN-Gateway IPSec-Implementierungen vonnten.
blicherweise wird der Tunnel bereits im Endgert initiert, es wird also zu diesem Zeitpunkz bereits eine IP-Verbindung zwischen dem Remote-AccessSystem und dem IPSec-Gateway vorausgesetzt. Gute IPSec-Clients bieten die Mglichkeit, automatisch die entsprechenden Verbindung zu einem geeigneten POP aufzubauen.
12.4.5
Branch-to-Branch-VPN
Ein weiterer IP-VPN-Dienste ist die Mglichkeit, verschiedene Standorte ber das Internet miteinander zu verbinden. Als Tunneling-Protokoll setzt man blicherweise das IP-Security-Protokoll (IPSec) ein um eine sichere bertragung zu gewhrleisten.
406
IPSecKonzentrator
KundenIntranet
VIAG InterkomNetz
IPSecKonzentrator
KundenIntranet
IPSec Gateway
ISDN PSTN
IPSecClient
POPs
IPSecClient
Control Tunnel
Abbildung 12.6: VIAG Interkom bietet sichere Remote-Access-VPN-Dienste auf Basis des IPSec-Protokolls an
Die Verbindungen zum Internet-Backbone der VIAG Interkom knnen mit verschieden schnellen Verbindungen aufgebaut werden, die mit ISDN-Whlverbindungen und 64-Kbit/s-Festverbindungen beginnen und bei E3-Verbindungen (34 Mbit/s) enden. Whlt der Kunde einen Bundled Service, so erfolgt, wie Sie in Abbildung 12.7 sehen, auch die Wartung und Konfiguration zentral vom Business Customer Care Center ber spezielle Management-Tunnel. Diese Tunnel sind IPSec-Tunnel, die aufgrund eines vordefinierten, festcodierten Filters nur auf die Management-Adresse des VPN-Gateways zugreifen knnen. Somit besteht keine Zugriffsmglichkeit in das Netzwerk des Kunden. Die Konfigurationen und Einstellungen knnen zentral im BCCC vorgehalten werden um beim Austausch eines Systems sofort wieder den alten Zustand herstellen zu knnen.
407
12 Fallstudien
VPN Gateway
KundenIntranet
VIAG InterkomNetz
VPN Gateway
KundenIntranet
VPN Gateway
VPN Gateway
KundenIntranet
Internet
Control Tunnel
Abbildung 12.7: Auch beim Branch-Office-VPN-Dienst setzt man bei VI aus Sicherheitsgrnden IP Security (IPSec) ein
408
Anhang
Weiterfhrende Literatur
Im Folgenden finden Sie eine nach Themen geordnete Reihe empfehlenswerter weiterfhrender Bcher zu verschiedenen, in diesem Buch behandelten Themen. Frame Relay Smith, Philip: Frame Relay. Principles and Applications. Addison-Wesley 1993, ISBN 0-201-62400-1. ATM Wilde, Alexander: SDH in der Praxis. VDE Verlag 1999, ISBN 3-8007-2446-4. DSL Ginsburg, David: Implementing ADSL. Addison-Wesley 1999, ISBN 0-201-65760-0 Starr, Thomas u.a.: xDSL: Eine Einfhrung. ISDN, HDSL, ADSL und VDSL. Addison-Wesley Verlag 2000. ISBN 3-8273-1574-3. IP Version 6 Huitema, Christian: Ipv6. Architektur und Implementierung. Addison-Wesley Verlag 2000. ISBN 3-8273-420-8. Quality-of-Service, Class-of-Service Huston, Geoff: Internet Performance Survival Guide. QoS Strategies for Multiservice Networks. Wiley & Sons 2000, ISBN 0-471-37808-9. Black, Daryl P.: Building Switched Networks. Multilayer Switching, QoS, IP Multicast, Network Policy and Service Level Agreements. Addison-Wesley 1999, ISBN 0-2013-7953-8 Kryptographie Schneier, Bruce: Angewandte Kryptographie. Protokolle, Algorithmen und Sourcecode in C. Addison-Wesley Verlag 1996, ISBN 3-89319-854-7. Wobst, Reinhard: Abenteuer Kryptologie. Methoden, Risiken und Nutzen der Datenverschlsselung. 3. Aufl. Addison-Wesley Verlag 2001, ISBN 3-8273-1815-7.
409
Anhang
Ihringer, Thomas: Diskrete Mathematik. Teubner Verlag 1999, ISBN 3-519-12125-5. Datensicherheit Pflegerer, Charles P.: Security in Computing. Prentice Hall 1997, ISBN 0-13-337486-6. Strobel, Stefan: Firewalls fr das Netz der Netze. Sicherheit im Internet, Einfhrung und Praxis. dpunkt Verlag 1997, ISBN 3-920993-31-4. Netzwerksicherheit Stallings, William: Sicherheit im Internet. Anwendungen und Standards. Addison-Wesley Verlag 2001, ISBN 3-8273-1697-9. Kaufman, Charlie, Radia Perlman, Mike Speciner: Network Security. Private Communication in a Public World. Prentice Hall 1995, ISBN 0-13-061466-1. IPSec Doraswamy, Naganand, Dan Harkins: IPSec. Der neue Sicherheitsstandard fr das Internet, Intranet und virtuelle private Netze. Addison-Wesley Verlag 2000, ISBN 3-8273-1634-0. Lee, Thomas: Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference. Kapitel 20 und 21. Microsoft Press Verlag 2000, ISBN 0-7356-0556-4. L2TP Shea, Richard: L2TP. Implementation and Operation. Addison-Wesley 2000, ISBN 0-201-60448-5. PPP Carlson, James D.: PPP. Design and Debugging. Addison-Wesley 1998, ISBN 0-201-18539-3. Digitale Signaturen, Zertifikate, PKI Bitzer, Frank, Klaus M. Brisch: Digitale Signatur. Grundlagen, Funktion und Einsatz. Springer-Verlag 1999, ISBN 3-540-65563-8. Warwick, Ford, Michael S. Baum: Secure Electronic Commerce. Building the InfraStructure for Digital Signatures and Encryption. Prentice Hall 1997, ISBN 0-13-476342-4.
410
Links
Links
Die folgenden Links bieten Zugriff auf die im VPN-Bereich wichtigsten Organisationen. Die Links wurden im Januar 2001 geprft. ICSA Labs URL: http://www.icsalabs.com Die ICSA Labs haben sich unter anderem die Zertifizierung von IPSec-Implementierungen zu einer ihrer Hauptaufgaben gemacht. Hier finden Sie auch weitere Informationen zum Thema Sicherheit, Firewalls und PKI. Virtual Private Network Consortium (VPNC ) URL: http://www.vpnc.org Das Virtual Private Network Consortium (VPNC) ist ein Konsortium, in dem sich der grte Teil aller namhaften VPN-Hersteller zusammengeschlossen hat. Auf den Webseiten des VPNC finden Sie viele Informationen, White Papers und vor allem ein umfassendes Herstellerverzeichnis. Internet Engineering Task Force URL: http://www.ietf.org/html.charters/wg-dir.html IETF IP Security Working Group URL: http://www.ietf.org/html.charters/ipsec-charter.html IETF IP Security Remote Access Working Group URL: http://www.ietf.org/html.charters/ipsra-charter.html IETF Public Key Infrastructure X.509 Working Group (PKIX) URL: http://www.ietf.org/html.charters/pkix-charter.html IETF Differentiated Services Working Group (PKIX) URL: http://www.ietf.org/html.charters/diffserv-charter.html IETF L2TP Extensions Working Group (PKIX) URL: http://www.ietf.org/html.charters/l2tpext-charter.html
411
Stichwortverzeichnis
A Access Link 52 Accounting 79, 382 ACT 227 Adaptive-Chosen-PlaintextAngriff 101 Adleman, Leonard 131 Adressmanagement 83 Advanced Encryption Standard 124,
325
Best-Effort 63 Betriebssicherheit 58 Branch-Office-VPN 328 Brute-Force-Angriff 99, 109, 324 C CA 164 Call Admission Priority 381 CBC 122, 191 CCP 280, 282 Cell Switching 23 Certificate Authority 164 Certificate Revocation List 166 Challenge Handshake Authentication Protocol 155, 280281 CHAP 155, 280281, 302 Chiffriermaschinen 97 Chipkarten 147, 160, 339 Chosen-Plaintext-Angriff 101 Cipher Block Chaining 122 Ciphertext Only Angriff 99 CIR 68 Class of Service 66 Collision Domain 48 Commited Information Rate 68 Compression Control Protocol 280, 282 Compulsory Tunneling 178 Configuration Log 382 Cookies 227 CoS 66 CRL 166 D Data Encryption Standard 93, 114 Datenintegritt 55 Datenvertraulichkeit 53, 91 DDoS 57 Decapsulation 170 Dedizierte VPN-Systeme 362 Delay 63 Denial-of-Service 57
Advanced Research Projects Agency 31 AES 124, 325 Geschwindigkeit 127 Hardwareimplementierung 126 Optimierung 128 Smartcards 127 Softwareimplementierung 126 Anti-Clogging-Token 227 ARPA 31 ARS 194 Asynchronous Transfer Mode 22 ATM 22 Service-Klassen 67 Zellen 23 Authentication Header 206 Authentifizierung 80, 145 Benutzer 146 Besitzbasierende 147 Biometrische 148 Kombinationsverfahren 147 Passthrough 159 Schwache 146 Starke 146 Wissensbasierte 146 Authentifizierung-Verfahren 146 B BayDVS 171 Benutzer-Authentifizierung 56, 95 Benutzer-Autorisierung 56
413
Denial-of-Service-Angriff 190 Dense Wave Division Multiplexing 33 DES 114, 324 Algorithmus 116 Entschlsselung 120 Funktion 118 S-Boxen 118 Schlsseltransformation 117 Teilschlssel 118 Triple-DES 120 Verschlsselung 117 DHCP 83 DHCP-Server 83 Dial-On-Demand-Routing 326 Diffentiated Services Code Point 69 Differentiated Services 69, 345 Differentielle Kryptoanalyse 101 Diffie, Whitfield 130 Diffie-Hellman 225, 324 Diffie-Hellman-Merkle-Verfahren 130 Diffie-Hellman-Verfahren 136 DiffServ 69, 345 DiffServ-Service-Klassen 71 Diffusion 101 Digitale Signaturen 150 Digitale Zertifikate 82, 150, 339, 351 Directory Services 84, 160 Direkte Vertrauensbeziehungen 162 Distributed DoS 57 DNS (Domain Name System) 83 DoS 57 DSCP 69 DSL 34, 331 DWDM 33 Dynamic Host Configuration Protocol 83 E ECHELON 96 Edge-Router (DiffServ) 70 Einmal-Code 148 EIR 68 Elektronische Signatur 168 Encapsulating-Security-Payload 209 Encapsulation 169 Ende-zu-Ende-Modell 172 Enigma 97
Ethernet 48 Header 50 Eulersche Totientenfunktion 136 EU-Signaturrichtlinie 168 Excess Information Rate 68 Exklusiv-Oder-Verknpfung 106 Extranet 350 F Falltr-Funktion 130, 132 Federal Information Processing Standard Publication 114 Feistel-Netzwerke 106, 117 Feistel-Zyklus 106 Fermats Theorem 136 FIPS-Pub 114 Firewalls 43, 56, 81, 346 Fortgeschrittene elektronische Signatur 168 Frame Relay 21 G Gefahrenanalyse 88 Generic Routing Encapsulation 176 GRE 176 H Hash-based Message Authentication Code 143, 189 Hashfunktionen 141 HDLC 278 Hellman, Martin 130 Hintertr-Funktion 130 HMAC 143, 189 HMAC-MD5-96 193 HMAC-SHA1-96 193 HTTP 78 Hybrid Link 52 Hyper Text Transfer Protocol 78 I ICSA 85 IETF 33 IKE 221, 244, 324 Aggressive Mode 245, 265 Authentifizierung 254 Hardware-Bescheuniger 273
414
Main Mode 245, 256 New Group Mode 244 Performance 272, 374 Quick Mode 244, 269 Schlsselerzeugung 251 Indirekte Vertrauensbeziehungen 152,
162
Initialisierungsvektor 123 Initiator 228 Integrated Services Digital Network 20 Interface-Sicherheit 58 Internet 30 Backbone 30 Verfgbarkeit 34 Internet Engineering Task Force 33 Internet Key Exchange 221 Internet Key Exchange Protokoll 244 Internet Security Asscociation and Key Management Protocol 222 Internet Service Provider 33, 352 Interoperabilitt 85 Intra-Provider-Modell 170 Inverse Elemente 136 IP Class of Service 31 CoS 31 Protokoll 31 TCP/IP 31 Version 6 187 VPN 24 IP Control Protocol 280, 282 IP Security 93 IP Security Protokoll 187 IPCP 282 IPSec 176, 187, 326 Adressmanagement 332 Anti Replay Service 194 Anti Replay Window 201 Architektur 196 Attribute 245 Authentication Header 206 Authentifizierung 193 Authenzitt 93 Client 177 Datenintegritt 93 Datenverschlsselung 93, 191
Denial-of-Service-Angriff 94 Encapsulating Security Payload 209 Hardwarebeschleuniger 217 Implementierungen 214 Integrittsprfung 193 Komprimierung 217 Lifetime 201 Mode 201 Paketauthentifizierung 189 Paketintegritt 188 Paketverarbeitung 205 Paketvertraulichkeit 189 Performance 215 PMTU Parameters 201 Routing 329 SAD 199 Schlsselmanagement 94 Security Association Database 199 Security Parameter Index 200 Security Poilcy 201 Security Policy Database 202 Selektoren 202 Sequence Number 201 Sequence Number Overflow 201 Sicherheitsassoziation (SA) 199 SPD 202 SPI 200 Standardisierung 196 Standards (RFCs) 197 Transportmodus 203 Tunnel Destination 201 Tunnelmodus 203 Verkehrsflussvertraulichkeit 189 Zukunft 219 IPSec Domain of Interpretation 222 IPSec secured L2TP 305 IPSec-DOI 222 IP-VPN-Service 360 ISAKMP 222 Aggressive Exchange 242 Austauschvorgnge 241 Authentication Method 248 Authentication Only Exchange 242 Authentifizierung 224 Base Exchange 242
415
Certificate Payload 235 Certificate Request Payload 236 Cookie 228 Delete Payload 239 Denial-of-Service-Angriff 226 Encryption Algorithm 248 Field Size 247, 250 Group Attributes 249 Group Order 247, 250 Hash Algorithm 248 Hash Payload 237 Header 228 Identification Payload 235 Identity Protection Exchange 242 Informational Exchange 243 Key Exchange Payload 234 Key Length 247, 250 Man-in-th-Middle-Angriff 227 Nonce Payload 237 Notification Payload 238 Nutzdaten-Header 231 Phase 1 241 Phase 2 241 Phasen 241 Pre-Shared Secret 224 PRF 247, 250 Proposal Payload 233 SA Life Duration 247, 250 SA Life Type 249 SA Payload 232 Schlsseltausch 225 Sicherheit 223 Sicherheitsassoziationen 222 Signature Payload 237 Transform Payload 233 Vendor ID Payload 240 ISDN 20 ISDN-Router 341 ISP 33 Ist-Aufnahme Technische Sicht 312
J Jitter 63 K Kennwort 146 Keyed Hashing 143 Klassifizierer 72 Known Plaintext Angriff 99 Kollision 141 Konfiguration 76 Konfusion 101 Kryptoanalyse 95, 99 Kryptographie 95, 101 Kryptologie 95 L L2F 180 L2TP 178, 277 Access Concentrator 285 Attribute Value Pairs 295 AVP 295 AVP-Verschlsselung 297 Benutzerauthentifizierung 300 Benutzernamen 287 Call 286 Compulsory Tunneling 292 Control Connection 286 Datenpakete 293 DNIS 288 LAC 285, 289 LNS 285, 289 Network Server 285 Performance 289 PPP-Tunneling 284 Sicherheit 303 Steuerungspakete 293 Tunnel 286 Tunnelaufbau 298 Tunnelauthentifizierung 304 Tunneling-Modelle 292 Virtueller LAC 293 Virtueller Remote Access 285
416
Voluntary Tunneling 292 L2TP/IPSec 305306 LADP 160 LAN 48 Switching 48 V-LAN 48 Lastverteilung 383 Lauschangriff 45 Lawineneffekt (Permutation) 105 Layer 2 Forwarding 180 Layer 2 Tunneling Protocol 178, 277 Layer-2-Tunneling 172 Layer-3-Tunneling 173 LCP 280 LCP Re-Negotiation 301 LDAP 84, 335 Lightweight Directory Access Protocol 84, 160, 335 Link Control Protocol 280 Lucifer-Chiffre 106, 115 LZS 282 M Management 76 Management Information Base 76 Massachusettes Institute of Technolgy 131 MD5 142 Mean Time Between Failure 373 MEM 34 Merkle,Ralph 130 Message Digest 5 142 MIB 76 MIB-Variablen 78 Micro Electronic Mirror 34 Microsoft Point-to-Point Encryption 180 Migrationsfhigkeit 75 Migrationsphase 82 MIT 131 Modulare Arithmetik 133 Modulo primitiv 133 MPLS 174 Label Distribution Protocol 175 Label Edge Router 175 Label Switching Router 175
MPLS-Router 174 MPPC 282 MPPE 180 MS-CHAPv2 180 MTBF 373 Multi Protokoll Label Switching 174 N NAT 83, 187, 341, 382 National Bureau of Standards 114 National Institute of Standards and Technology 115 National Security Agency 96, 114 NBS 114 Network Address Translation 83, 187,
341
Network Time Protocol 383 NIST 115, 124 NSA 96 NTP 383 O Oakley 243 Oakley Key Determination Protocol 243 Oakley-Gruppe 2 5 244 Oakley-Gruppe-1 243 ffentlicher Schlssel 111, 150151 One-Time-Token 148 OSPF 384 Out-of-Band-Zugriff 335 P Padding 113 Paket-Authentifizierung 55 PAP 155, 281 Password Authentication Protocol 155,
280281
Passwort 146 P-Box 105 Per Hop Behaviour 69 Perfect Forwarding Secrecy 245 Performance ATM 62 Frame Relay 62 IP-VPN 62 Standard-Festverbindungen 61
417
Whlverbindungen 61 Permanent Virtual Circuit 21 Permutation 104 Expansion 105 Kompression 105 Persnliche IdentifikationsNummer 147 PFS 245 PHB 69 PHB-Router 72 Physische Sicherheit 58 PIN 147 PKI 81, 162, 335 PKIX 339 Point of Presence 41 Point-to-Point Protocol 277 Point-to-Point Tunneling Protocol 180 Policy-Server 73 POP 41 PPP 155, 277 PPTP 180 Pre-Shared Secret 352 Primrmultiplexanschlu 37 Primzahlen 132 Erzeugung 132 Hufigkeit 132 Privater Schlssel 111, 151 Provider-Enterprise-Modell 171 Pseudo-Zufallszahlen 140 Public Key Infrastrcture 162 Public Key Infrastructure X.509 339 Public-Key-Infrastruktur 81 Public-Key-Kryptographie 129, 131 Public-Key-Verfahren 323 PVC 21 Q QoS 62, 327 ATM 67 Frame Relay 68 IP-Protokoll 69 IP-VPN 74 Standard-Festverbindungen 67 Whlverbindungen 66 Qualitt Flussbasierend 65
Klassenbasierend 66 Vorherbestimmbar 65 Qualittsparameter 63 Quality of Service 62 R Rabin-Miller Algorithmus 133 RAC 37, 278 RADIUS 79, 157 Random Function 140 Registration Authority 164 Relativ prim 133 Remote Access 278 Remote Access Concentrator 37, 278 Remote Authentication Dial In User Service 157 Remote-Access Kostenvergleich 25 Remote-Access-VPN 328 Replay Attack 190, 194 Request for Comment 31 Responder 228 Ressource Reservation Protocol 66 RFC 31 Rijndael 128, 325 RIP 384 Rivest, Ronald 131 RND 140 Rollout 340 Rotormaschinen 97 RSA 131, 226, 323 RSA-Verfahren 138 RSVP 66, 345 S S2M 37 SA Authentication Algorithm 246247 SA Life Duration 246 SA Life Type 246 S-Box 103 Schlsselmanagement 54, 150151 Secure Hash Algorithm 143 SecurID 339 Security Log 382 Security Policy 80 Service Level Agreement 30
418
Service Level Agreements 353 Service Provider 352 SHA 143 Shamir, Adi 131 Shaper 72 Sicherheit Analyse 88 Netzwerkschicht 93 Unternehmensdatennetze 87 VPN 87 Sicherheitsstrategie 80, 322, 346 Sicherheitstechnologie 87 SigG 167 Signaturgesetz 167 Simple Network Management Protocol 76 Skalierbarkeit 75 SLA 30, 353 Backbone-Verfgbarkeit 353 Bandbreite 354 Compulsory Tunneling 356 Dial-In Firewall 356 Dial-In QoS 356 Einwhlverfgbarkeit 353 Ende-zu-Ende-Verfgbarkeit 354 Installationszeiten 355 Maximale Fehlerrate 354 Paketblockierung 355 Paketverzgerung 354 QoS-Klassen 355 Reparaturzeiten 354 Verfgbarkeit 353 Vertragsstrafen 355 Small Office Home Office 341 SNMP 76 SNMP-Trap 382 SOHO 341 Spaltentransposition 104 Split-Management 45 Split-Tunneling 338 SSL 77 Startup-Unternehmen 28 Stateful Packet Inspection 348 Substitution 102 Monoalphabetisch 102 Nichtlinear 103
Polyalphabetisch 102 SVC 21 Switched Virtual Circuit 21 Symmetrischen Verfahren 323 System Log 382 T TMS 299 Token-Karten 147148, 339 TOS 69 Transposition 104 Trap 76, 382 Trap door function 130, 132 Triple-DES 120, 324 Trunk 52 Trust-Center 167 Tunneling 169 Tunneling-Modelle 170 Tunneling-Protokolle 169, 172, 326, 376 Tunnel-Management-System 299 Tunnelswitching 382 Type-of-Service-Byte 69 U berwachung (Management) 78 V Verfgbarkeit 59 Verkehrsbeziehungen 313 Verkehrsprofil 313 Verschleierung 97 Verschlsselung 92, 97 Asymmetrische 111 Datenblock 113 Datenstrom 113 Public Key 109 Secret Key 109 Symmetrische 109 Verfahren 108 Verschlsselungsverfahren Asymmetrische 129 Symmetrische 113 Vertrauensbeziehungen 150151 Vertrauensmodelle 162 Verzeichnisdienst 160 Verzeichnisdienste 84, 335 Verzgerungszeit 63
419
Virtual Router Redundancy Protocol 344 V-LAN Adressbasierend 50 nach IEEE802.1q 50 Portbasierend 50 Protokollbasierend 48 Voluntary Tunneling 179 VPN Accounting 333 Administration 335 Admission Control 345 Arten 37 Ausfallsicherheit 343 Auswahl 361 Authentifizierung 315, 379 Authentifizierungsverfahren 351 Autorisierung 316 Backup 344 Bandbreite 344 Bandbreitenmanagement 344 Branch-Office 41, 359 Client-Rollout 340 Clients 336 Clientsoftware 385 Datenvertraulichkeit 315 Design 309 Dienste 43 Durchsatz 331 Extranet 42 Hersteller Auswahl 366 Internet-VPN 24 Intranet 47 IP 44 IP-Adressmanagement 332 IP-VPN 24, 30 Ist-Aufnahme 310 Lastverteilung 345 Layer-2 46 Loadbalancing 345 Logging 333
Markt 28 Marktentwicklung 30 Migrationsphase 322 Performance 363 QoS 380 Realisierung 328 Redundanz 343 Remote Access 330 Remote-Access 37, 356 Remote-Access-VPN 24 Routing 329, 384 Schnittstellen 375 Sicherheit 315, 334, 377 Site-to-Site 41 Skalierbarkeit 342 Sprach-VPN 19 Systemdurchsatz 344 Typ 325 bergangsphase 322 Unified-VPN 19 VPN-Gateway 346 VPN-Planung 310 VPN-Zusatzfunktionen 362 VRRP 344, 383 W Web-based-Management 77 X X.25 21 X.509 336 X.509-Zertifikate 153 Z Zertifikate Lebensdauer 165 Sperrlisten 165 Verteilung 165 Zufallszahlen 140 Zugangs-Kontrollsystem 145 Zugriffsschutz 58
420
Copyright
Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen eBook-Zusatzdaten sind urheberrechtlich geschtzt. Dieses eBook stellen wir lediglich als Einzelplatz-Lizenz zur Verfgung! Jede andere Verwendung dieses eBooks oder zugehriger Materialien und Informationen, einschliesslich der Reproduktion, der Weitergabe, des Weitervertriebs, der Platzierung im Internet, in Intranets, in Extranets anderen Websites, der Vernderung, des Weiterverkaufs und der Verffentlichung bedarf der schriftlichen Genehmigung des Verlags. Bei Fragen zu diesem Thema wenden Sie sich bitte an: mailto:info@pearson.de
Zusatzdaten
Mglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die Zurverfgungstellung dieser Daten auf der Website ist eine freiwillige Leistung des Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis
Dieses und andere eBooks knnen Sie rund um die Uhr und legal auf unserer Website
(http://www.informit.de)
herunterladen

Lipp - VPN Virtuelle Private Netzwerke

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lipp - VPN Virtuelle Private Netzwerke

Hochgeladen von

Copyright:

Verfügbare Formate

VPN Virtuelle Private Netzwerke

VPN Virtuelle Private Netzwerke

An imprint of Pearson Education

Performance 3.3.1 3.3.2 3.3.3

Quality-of-Service (QoS) 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6

3.7 3.8 3.9

Koexistenz zu traditionellen WAN-Strukturen Adressmanagement Interoperabilitt

Die Grundlagen der Kryptographie

4.2.5 4.2.6 4.3 4.4

Einfhrung in die Kryptographie Verschlsselungsverfahren

4.5 4.6 4.7

AES-Geschwindigkeit und Optimierungsmglichkeiten 127

Asymmetrische Verschlsselungsverfahren 4.8.1 4.8.2 4.8.3

4.10 Das RSA-Verfahren 4.11 Hashfunktionen

Authentifizierungssysteme und -protokolle 5.3.1 5.3.2 5.3.3 5.3.4

Nicht standardisierte Protokolle

Kryptographische Verfahren in IPSec

IPSec-Betriebsmodi 7.6.1 7.6.2

IPSec-Einsatzszenarien 7.7.1 7.7.2 7.7.3

IPSec-Protokolle 7.8.1 7.8.2 7.8.3

IPSec-Implementierungen 7.9.1 7.9.2

7.10 Betrachtungen zur IPSec-Performance 7.11 Zuknftige Entwicklungen

Das Oakley Key Determination Protocol

Der Aufbau von IKE

Der IKE Main Mode

Der IKE Aggressive Mode 8.7.1 8.7.2 8.7.3

PPP-Tunneling mit L2TP

Die Sicherheit von L2TP IPSec secured L2TP

11.4.3 11.4.4 11.4.5 11.4.6 11.4.7 11.4.8 11.4.9

Leistung Schnittstellen Tunneling-Protokolle Sicherheit Authentifizierung Quality-of-Service und Profile

373 375 376 377 379 380

12.2 Studie 2: Der Blutspendedienst des DRK

Virtuelle private Netzwerke

1 Virtuelle private Netzwerke

Geschichte und Technologien

Geschichte und Technologien

1 Virtuelle private Netzwerke

Geschichte und Technologien

1 Virtuelle private Netzwerke

1 Virtuelle private Netzwerke

Rahmenbedingungen fr den Einsatz

Cisco Check Point

Lucent IBM Axent IRE

Rahmenbedingungen fr den Einsatz

IP-VPN (US) IP-VPN (Rest) IP-VPN (Global)

Total global IP-VPN service revenue $US m

Abbildung 1.5: Eine Prognose zur weltweiten Marktentwicklung von IP-VPNs

1 Virtuelle private Netzwerke

Umsatz in Millio nen Dolla r

1 Virtuelle private Netzwerke

IP-VPNs und das Internet

IP-VPNs und das Internet

30% 34% 20% 14%

1 Virtuelle private Netzwerke

NAP: Network Access Point Zustzlich mgliche Verbindungen

Entwicklungen und Ausblicke

Entwicklungen und Ausblicke

1 Virtuelle private Netzwerke

Entwicklungen und Ausblicke

10.000 9.000 8.000

ISDN PSTN GSM

Virtuelle Verbindung (Tunnel)

Kunde Kunde Kunde

Abbildung 2.7: Layer-2-VPN-Dienste werden meist fr Remote-Access-VPNs eingesetzt.