Point-To-Point-Tunneling-Protocol (PPTP)

Jens Haines (2237318)

Florian Hirdes (2233105)

Universität Kassel, im Juli 2005

1

Inhalt Einführung ...........................................................................................................................................3

PPTP: Hintergrund...........................................................................................................................3 Was ist Tunneling?...........................................................................................................................3 Point-To-Point Protocol (PPP).........................................................................................................4

PPTP: Protokollaufbau.........................................................................................................................5 PPTP-Architektur.............................................................................................................................5 PPTP Sessions..................................................................................................................................6 Der PPTP-Header.............................................................................................................................7 Control Connection..........................................................................................................................7

Start-Control-Connection-Request...............................................................................................8 Start-Control-Connection-Reply................................................................................................10 Stop-Control-Connection-Request.............................................................................................11 Stop-Control-Connection-Reply ................................................................................................12

Der Verbindungsauf- und -abbau...................................................................................................12 Echo-Request .............................................................................................................................14 Echo-Reply.................................................................................................................................14

Generic Routing Encapsulation (GRE)..............................................................................................15 Der GRE-Header............................................................................................................................15 Routing in GRE..............................................................................................................................16 Der erweiterte GRE-Header...........................................................................................................17

Sicherheit ...........................................................................................................................................18 Authentifizierung ...........................................................................................................................18

PAP ............................................................................................................................................18 CHAP.........................................................................................................................................19 MS-CHAP-V2............................................................................................................................21

Verschlüsselung .............................................................................................................................22 PPP Encryption Control Protocol (ECP) und DESE .................................................................22 RC4 ............................................................................................................................................23

Zusammenfassung..............................................................................................................................24 Quellen:..............................................................................................................................................24

2

Einführung Im folgenden sollen das Point-To-Point Tunneling Protocol und die ihm zugrundeliegenden und in seinem Umfeld eingesetzten Technologien behandelt werden. Dazu wird nach einer kurzen Einführung zunächst ein allgemeiner Einblick in die Tunneling-Technologie und die Funktionsweise von PPP gegeben. Anschließend wird ausführlich auf den PPTP Protokollaufbau, das Sitzungsmanagement und die Verbindungssteuerung eingegangen. Einer genaueren Betrachtung sollen der GRE-Header und seine für PPTP vorgenommenen Modifikationen erfahren, bis wir uns schließlich dem Thema Sicherheit widmen, in dem ein besonderes Augenmerk auf Authentifizierungstechnologien wie CHAP gelegt werden soll. Zusätzlich wird eine Erklärung der grundlegenden Verschlüsselungs-Mechanismen und ein Überblick über die wichtigsten verwendeten Algorithmen gegeben.

PPTP: Hintergrund Das Point-to-Point Tunneling Protocol (PPTP) ist ein von einem Herstellerkonsortium entwickeltes Protokoll zum Aufbau eines Virtuellen Privaten Netzes (VPN). Mitglieder dieses Herstellerkonsortiums sind unter anderem das Unternehmen Microsoft Corporation sowie Ascend Communiactions, 3Com, ECI-Telematics und US Robotics [1]. Microsoft und US Robotics haben im März 1996 zum erstenmal PPTP im Rahmen der Networld demonstriert. Kurz darauf wurde es im April 1996 zuerst in Windows NT 4.0 implementiert. Mit Hilfe von PPTP lassen sich sichere Tunnel zwischen zwei LANs (Local Area Networks) über ein öffentliches Netz wie zum Beispiel das Internet aufbauen. Der große Vorteil von PPTP ist hierbei, dass kein bestimmtes Protokoll in den LANs vorhanden sein muss. Es ist somit möglich Protokolle wie IP, IPX oder NetBEUI zu tunneln. PPTP kann als eine Erweiterung von PPP (Point-toPoint Protocol) angesehen werden. Es basiert auf den Protokollen PPP und IP [2]. In letzter Zeit verliert PPTP mehr und mehr an Bedeutung. Es wird durch L2TP (Layer 2 Tunneling Protocol) abgelöst, welches aus den beiden Protokollen PPTP und L2F (Layer 2 Forwarding) hervorgegangen ist. Es vereint von beiden Protokollen die positiven Eigenschaften. Jedoch ist PPTP nach wie vor im Einsatz. Es wird unter anderem an einigen Universitäten eingesetzt, um den dortigen Studenten Zugriff zum Uni internen Netz zu gewähren. Außerdem wird es in Österreich und in den Niederlanden für die dortige DSL-Verbindung genutzt [3]. In Deutschland wird hingegen PPPoE (Point-to-Point over Ethernet) für diesen Zweck eingesetzt.

Was ist Tunneling? Im Allgemeinen bezeichnet man als Tunneling den Transport eines Netzwerkprotokolls (bzw. der unter Verwendung dieses Protokolls verpackten Nutzdaten) eingekapselt in ein anderes. Auf diese Weise kann ein Protokoll verwendet werden, ohne dass es zwingend der Infrastruktur des vermittelnden Netzes bekannt sein muss. Meist wird diese Technologie verwendet, um zwei oder mehr Netze über ein drittes (z.B. das ATM der Telefongesellschaft oder IP-Basierte Netze des Internet) miteinander zu verbinden.

Diese Verbindung kann entweder auf Layer 2 oder 3 des OSI/ISO-Referenzmodells stattfinden. PPTP stellt (wie auch L2F und L2TP) diese Verbindung auf Layer 2 her; auf Layer 3 wird in der Regel IPSec verwendet. Die Layerangabe bezieht sich dabei auf das transportierte Protokoll: Layer 2 Tunneling verpackt normalerweise PPP-Frames, denen ein Header des Tunneling-Protokolls

3Layer 2 Tunneling [4]

vorangestellt wird in den Nutzdatenteil eines IP-Paketes. Auf diese Weise entsteht eine Art virtueller Punkt-zu-Punkt-Leitung zwischen dem Quell- und Zielrechner, auch wenn sie unter Umständen durch mehrere weitere Rechner und physikalische Netze getrennt sind. So kann Gebrauch von allen Möglichkeiten des transportierten Protokolls (wie z.B. der Authentifizierung und Verschlüsselung (s.u.)) gemacht werden. Layer 3 Tunneling hingegen verpackt IP-Pakete in andere IP-Pakete, was sie im Gegensatz zu Layer-2-Tunneling-Protokollen nicht Multiprotokollfähig macht. Das bedeutet, dass in dem transportierten Frame verschiedene Layer 3-Protokolle enthalten sein können (z.B. IPX, Appletalk, IP, NetBIOS, NetBEUI), während ein Layer-3-Tunneling-Protokoll auf ein einziges Protokoll (in der Regel IP) festgelegt ist. In der Praxis verbindet man zwei Netze über das Internet indem man jeweils dedizierte Server installiert, welche die im Format des verwendeten Protokolls vorliegenden Pakete (bzw. Frames) mit einem zusätzlichen IP-Header versehen, der als Zieladresse die Adresse des gegenseitigen Servers trägt, und das so entstandene IP-Paket an das Internet weiter gibt, wo es auf die übliche Weise geroutet und an den Zielserver zugestellt wird. Dort wird der zusätzliche IP-Header wieder entfernt und dem IP-Nutzdatenfeld das „eigentliche“ Datenpaket entnommen, welches jetzt anhand der in ihm erhalten gebliebenen Adressierung problemlos im Zielnetz zugestellt werden kann.

Layer 3 Tunneling [4]

Diese Art der Verwendung eines Tunnels, nämlich der Transport von privaten Daten über ein öffentliches Netz nennt man Virtuelles Privates Netz (Virtual Private Network, VPN). Vielfach wird der Datenstrom innerhalb des Tunnels verschlüsselt, um ihn vor der Einsicht Dritter zu verbergen. Diese Anwendung ist durchaus verbreitet, um etwa Außendienstmitarbeitern den Zugang zum Firmen-Intranet über eine schnelle und kostengünstige Internetverbindung zu ermöglichen, anstatt z.B. eine direkte Modemverbindung herzustellen. Auch die Universität Kassel verwendet diese Technologie, um den Notebooks der Uni-Angehörigen die Verbindung zum Uni-Netz über ein (ansonsten ungesichertes) Wireless LAN zu ermöglichen. [4] [5]

Point-To-Point Protocol (PPP) Im Gegensatz zu Local Area Networks (LANs), welche in der Regel auf Mehrfachszugriffskanälen arbeiten und zu diesem Zweck Gebrauch von der MAC-Teilschicht der Sicherungsschicht machen(Broadcast-Netze), bestehen Wide Area Networks (WANs) vorwiegend aus Punkt-zu-Punkt-Verbindungen, an denen nur jeweils zwei Rechner beteiligt sind.

Im Falle des Internet handelt es sich dabei zum einen um die PCs (oder Router) der Heimanwender, die mit dem Server ihres Service Providers über Wähl- oder DSL-Leitungen verbunden sind, zum anderen um die Router von Firmen- oder Universitätsnetzen, die über Standleitungen an große Backbones angebunden sind. Das dazu verwendete Protokoll ist das Punkt-zu-Punkt-Protokoll (Point-To-Point-Protocol) PPP. Als ISO/OSI-Layer 2 Protokoll stellt PPP Möglichkeiten zur Fehlererkennung und Rahmenbildung, zur Bestimmung von Leitungs- und

4Tunneling zwischen zwei LANs [7]

Verbindungsmerkmalen und zur Vorbereitung der Verbindung für ein Layer 3 Protokoll bereit. PPP-Rahmen transportieren dabei, sobald die Verbindung physikalisch aufgebaut wurde, zunächst LCP-Rahmen (Link Control Protocol), mithilfe dessen Leitungsparameter wie Kodierungen, Synchronisierung, etc. ausgetestet bzw. ausgehandelt werden. Hier kann zum Beispiel auch die Verkleinerung des PPP-Headers durch Verkürzung nicht benötigter Felder vereinbart werden. Anschließend wird über in PPP-Rahmen verpackte NCP-Pakete (Network Control Protocol) die Konfiguration für die Vermittlungsschicht erstellt. Soll auf dieser zum Beispiel IP verwendet werden, wird in diesem Zug eine IP-Adresse für den Host bezogen. Der Abbau der Verbindung verläuft analog in umgekehrter Reihenfolge. Jeder PPP-Rahmen besteht insgesamt aus 4-10 Bytes (standardmäßig 8) Verwaltungs- und einer Variablen Menge (1500 Bytes) an Nutzdaten. PPP ist zeichenorientiert und weitgehend unabhängig vom transportierten Protokoll: standardmäßig unterstützt (in Form eines vordefinierten Codes als Eintrag im Protokoll-Feld des Headers) werden z.B. IP, IPX und AppleTalk sowie „Verwaltungsprotokolle“ wie LCP und NCP. Als Teil des Verbindungsvorgangs kann auch eine Authentifizierung der Beteiligten erfolgen. Zu diesem Zweck kann beispielsweise CHAP (s.u.) über PPP transportiert werden. [5] [6]

PPTP: Protokollaufbau Wir wollen nun ein paar grundlegende Funktionen und Komponenten des Point-to-Point Tunneling Protokolls betrachten. Es ist zu bemerken, dass jede PPTP-Verbindung aus einer Kontrollverbindung (Control Connection) und einem Tunnel besteht. Durch diesen Tunnel werden die Benutzerdaten gesendet. Es ist möglich mehrere Sessions durch einen Tunnel zu senden. Sehen wir uns nun zunächst einmal die PPTP-Architektur und die unterschiedlichen Möglichkeiten des Gebrauchs von PPTP Sessions an.

PPTP-Architektur

Quelle: [8]

Die PPTP-Architektur teilt sich in zwei logische Bereiche auf. Zum einen ist da der PPTP Access Concentrater (PAC). Dieser symbolisiert die Clientseite, und ist entweder im Clientrechner selbst oder beim Internet Service Provider (ISP) implementiert. Zum anderen ist da der PPTP Network Server (PNS) der im allgemeinen im Remote Access Server (RAS) des Local Area Networks (LAN) der Firma implementiert ist. Der PAC verwaltet die Verbindungen zum PNS. Der PNS ist für das Routing der Pakete verantwortlich. Der PAC stellt eine PPP Verbindung zum PNS her. Nach der Authentifizierung bekommt er vom PNS eine IP-Adresse aus dem LAN zugewiesen. Danach beginnt er PPTP-Pakete zu versenden [8]. Kommen wir nun zu den unterschiedlichen Möglichkeiten des Verbindungsaufbaus von PPTP

5

Sessions.

PPTP Sessions Es gibt im Prinzip 2 Szenarios einer PPTP-Verbindung über das Internet. Bei der ersten ist PPTP beim Internet Service Provider (ISP) aktiviert, und der Klient benötigt nur PPP. Bei der zweiten ist PPTP beim Klient selbst aktiviert, und der ISP wird nur für den Internetzugang benötigt. Der Hauptunterschied liegt darin wo PPTP implementiert werden muss, entweder auf der Clientseite, oder beim ISP. Szenario 1:

Quelle: [9]

Bei diesem Szenario benötigt der Klient kein PPTP. Er baut eine Verbindung mit dem Front End Processor (FEP) des ISPs auf. PPTP muss bei diesem FEP (üblicherweise ein Router oder eine Bridge) aktiviert sein. Möchte der Klient nun eine Verbindung mit dem Remote Access Server der Firma aufbauen so erstellt der FEP das VPN indem er eine PPTP-Verbindung mit dem RAS aufbaut und alle Informationen über diese Verbindung tunnelt. Die Authentifizierung und Verschlüsselung wird vom RAS gesteuert. Bei diesem Szenario benötigt der Klient nur das Point-to-Point Protokoll, somit können durchaus auch von anderen Betriebssystemen wie Unix, Mac oder OS/2 aus auf den RAS zugegriffen werden [9]. Szenario 2:

Quelle: [9]

Dieses Szenario setzt voraus, dass der Klient PPTP beherrscht. Zuerst wählt sich der Klient bei seinem ISP ins Internet ein und erstellt eine PPP-Session. Dann wählt sich der Klient bei seinem RAS der Firma ein und erstellt eine PPTP-Verbindung mit diesem. Auch hier steuert der RAS (im Bild der NT Server) die Authentifizierung und die Verschlüsselung. Die PPP-Pakete werden nun durch diese Verbindung zum RAS gesendet. Der Klient ist nun im Prinzip ein ganz normaler Rechner der sich verhält als würde er sich direkt im Firmen-LAN befinden. Bei diesem Szenario benötigt der ISP keine PPTP-Unterstützung. Jedoch können nur Klienten sich einloggen wenn sie PPTP-Installiert haben [9]. Anmerkung: Es gibt derzeit auch Software für Unix die es erlaubt PPTP zu verwenden. Auch ein

6

PPTP-Server ist in Unix umgesetzt worden. [10] [11] Nachdem wir nun die PPTP-Architektur und die unterschiedlichen Möglichkeiten von PPTP Sessions betrachtet haben schauen wir uns einmal den PPTP-Header an.

Der PPTP-Header

Quelle [13]

Der PPTP-Header ist 32 Bits lang und besteht mindestens aus den oben angegebenen Feldern. Dabei bedeuten die Felder folgendes: Length (16 Bits) Die Gesamtlänge der PPTP-Nachricht inklusive dem Header PPTP Message Type (16 Bits) Hierbei sind folgende Werte gültig:

1. Control Message 2. Management Message

Auf die Control Messages wird später im einzelnen eingegangen. Management Messages sind derzeit noch keine definiert. Diese Nachrichten sollen es später einmal einem PNS erlauben den Status eines PACs abzufragen. Magic Cookie (32 Bits) Dieser Wert ist bei jeder Nachricht konstant 0x1A2B3C4D (Hexadezimal). Dieser Wert wird mit jeder Nachricht gesendet, damit der Empfänger sicherstellen kann, das er noch mit dem Sender synchronisiert ist. Das Magic Cookie ist nicht dazu gedacht eine Verbindung erneut zu synchronisieren. Stellt der Empfänger fest, das er nicht mehr synchron zum Sender ist, so hat dies zur Folge, dass die Verbindung beendet wird. Data (Variable Länge) In diesem Feld stehen die Daten. Bis jetzt sind wie gesagt nur Control Messages definiert worden. Diese Nachrichten werden benötigt um eine Kontrollerbindung aufzubauen. Darauf wird später noch einmal im einzelnen eingegangen.

Control Connection Bevor überhaupt PPP-Tunneling stattfinden kann muss zwischen dem PNS und dem PAC eine sogenannte Control Connection (Kontrollverbindung) aufgebaut werden. Diese Verbindung ist eine einfache TCP-Verbindung auf Port 1723 [12], über die Kontrollnachrichten zwischen dem Client

7

und dem Server ausgetauscht werden können. Auf der Seite des Verbindungserstellers kann der Port beliebig gewählt werden. Für jedes PNS-PAC Paar existieren ein Tunnel und eine Control Connection. Die Control Connection ist verantwortlich für den Aufbau, die Erhaltung und den Abbau der einzelnen Sessions, die durch den Tunnel gehen. Die Control Connection kann entweder vom Client oder vom Server aufgebaut werden. Dies geschieht nachdem die erforderliche TCP-Verbindung erfolgreich aufgebaut wurde, durch den Austausch von Start-Control-Connection-Request bzw. –Reply Nachrichten. Ist somit die Control Connection aufgebaut, kann vom Client oder vom Server eine Session eröffnet werden, indem entweder auf eine eintreffende Anfrage geantwortet wird, oder eine Anfrage selber formuliert wird. Die Control Connection selber wird durch Echo-Request bzw. –Reply Nachrichten aufrecht erhalten. Dadurch wird sichergestellt dass ein Verbindungsverlust in einem bestimmten Zeitrahmen erkannt werden kann. Die bis jetzt festgelegten Kontrollnachrichten sind:

Kontrollnachricht

Nummer:

Control Connection Management

Start-Control-Connection-Request 1 Start-Control-Connection-Reply 2 Stop-Control-Connection-Request 3 Stop-Control-Connection-Reply 4 Echo-Request 5 Echo-Reply

6

Call Management

Outgoing-Call-Request 7 Outgoing-Call-Reply 8 Incomming-Call-Request 9 Incomming-Call-Reply 10 Incomming-Call-Connected 11 Call-Clear-Request 12 Call-Disconnect-Notify

13

Error Reporting

WAN-Error-Notify

14

PPP Session Control

Set-Link-Info 15 Quelle: [12] Im folgenden wird auf einige dieser Nachrichten noch einmal besonders eingegangen. Es soll anhand eines Beispiel von einem Verbindungsaufbau und der Aufrechterhaltung der Verbindung der Gebrauch dieser Nachrichten erläutert werden. Zunächst werden die dafür benötigten Nachrichten im einzelnen vorgestellt.

Start-Control-Connection-Request Der Start-Control-Connection-Request ist eine PPTP Nachricht, die zum Verbindungsaufbau benötigt wird. Dieser Request kann entweder vom Client oder vom Server gesendet werden. Bevor keine Control Connection besteht können keine PPTP Nachrichten gesendet werden. Bevor der

8

Start-Control-Connection-Request gesendet werden kann muss eine TCP-Verbindung auf Port 1723 aufgebaut werden. Dabei kann es zu einer Kollision von zwei Startanfragen kommen, jedoch dazu später mehr. Im folgenden wird die Start-Control-Connection-Request Nachricht im einzelnen betrachtet [12].

Quelle: [13]

Length Die gesamte Länge der PPTP Nachricht inklusive dem PPTP Header. PPTP Message Type Dieser Wert ist 1, was für Kontrollnachricht steht. Magic Cookie Dieser Wert ist bei jeder Nachricht konstant 0x1A2B3C4D (Hexadezimal). Control Message Type Dieser Wert ist 1, was für Start-Control-Connection-Request steht (siehe obere Tabelle). Reserved0, Reserved1 Diese Felder müssen 0 sein. Protocol Version In diesem Feld steht die Protokollversion die der Sender verwenden möchte. Framing Capabilities Ein Bit-Set in dem die Art von Framing steht, die der Sender anbieten kann. Mögliche Werte hier sind:

1. Asynchrones Framing 2. Synchrones Framing

Bearer Capabilities Ein Bit-Set in dem die Möglichkeiten für die Signalträger stehen, die der Sender dieser Nachricht

9

anbieten kann. Mögliche Werte sind hier:

1. Analoger Zugang wird unterstützt 2. Digitaler Zugang wird unterstützt

Maximum Channels Hier steht die maximale Anzahl von PPP Sessions die der PAC unterstützt. Sendet ein PNS den Start-Control-Connection-Request sollte dieser Wert 0 sein. Der PAC muss diesen Wert dann ignorieren. Firmware Revision Dieses Feld beinhaltet die Firmware Revision Nummer des PAC, sofern die Anfrage von ihm kommt. Stellt der PNS die Anfrage, so enthält das Feld die Version des PPTP-Treibers den dieser verwendet. Host Name In diesem Feld steht der DNS Name des Anfragestellers (PAC oder PNS). Wenn dieser Name weniger als 64 octets beansprucht, wird der Rest mit Nullen aufgefüllt. Vendor Name Dieses Feld beinhaltet einen String, der den Typ des PACs der verwendet wird beschreibt. Wird die Anfrage vom PNS gestellt, so beinhaltet dieses Feld einen String der die Software die der PNS verwendet beschreibt. Auch hier wird der evtl. vorhandene Rest des Feldes mit Nullen aufgefüllt.

Start-Control-Connection-Reply Der Start-Control-Connection-Reply ist die Antwort auf einen empfangenen Star-Control-Connection-Request. Er beinhaltet einen Statuscode, der das Ergebnis des Verbindungsaufbauversuches repräsentiert. Im folgenden werden nur die unterschiede des Start-Control-Connection-Replys zum Start-Control-Connection-Request betrachtet [12]. Alle anderen Felder sind identisch zu verstehen.

Quelle: [13]

10

Control Message Type Diesmal ist dieser Wert 2, was für Start-Control-Connection-Reply steht (siehe Tabelle). Result Code Anstatt Reserved1 steht im Start-Control-Connection-Reply der Result Code und ein Error Code. Der Result Code repräsentiert das Ergebnis des Verbindungsaufbaus. Gültige Werte sind:

1. Verbindungsaufbau erfolgreich 2. General Error – Der Error Code gibt den aufgetretenen Fehler an 3. Der Kanal existiert bereits 4. Der Anfragende ist nicht authentifiziert für einen Verbindungsaufbau 5. Die Protokollversion des Anfragenden wird nicht unterstützt

Error Code Dieses Feld ist im Normalfall 0, es sei denn ein Fehler ist aufgetreten. Wenn ein Fehler eingetreten ist, so wird der Result Code auf 2 (General Error) gesetzt, und der Fehlercode in dieses Feld geschrieben. Gültige Werte für diesen Fehlercode sind:

0. (None) – Es ist kein Fehler aufgetreten 1. (Not-Connected) – Es existiert noch keine Kontrollverbindung zwischen Client und Server 2. (Bad-Format) – Die Länge oder der Magic Cookie sind nicht korrekt 3. (Bad-Value) – Einer der Felder war zu Groß, oder ein Reserved-Feld war nicht 0 4. (No-Resource) – Es stehen nicht genügend Ressourcen zur Verfügung um diese Anfrage

jetzt zu bearbeiten 5. (Bad-Call ID) – Die Call ID ist nicht gültig in diesem Zusammenhang 6. (PAC-Error) – Ein Vendor-spezifischer Fehler ist aufgetreten beim PAC

Anmerkung: Es sollte erwähnt werden, dass in diesem Zusammenhang ein Fehler im RFC immer wieder auftritt. Die General Error Codes stehen nicht wie ständig beschrieben in Abschnitt 2.2 sondern in Abschnitt 2.16. Dies ist wohl auf einen Copy und Paste Fehler zurückzuführen. Alle anderen Felder sind identisch mit den Feldern des Start-Control-Connection-Request.

Stop-Control-Connection-Request Der Stop-Control-Connection-Request ist eine Nachricht, die von einer Seite der Verbindung (PNS oder PAC) gesendet werden kann, um der anderen Seite mitzuteilen, dass die Kontrollverbindung beendet werden soll. Wie auch bei den beiden Verbindungsaufbau Nachrichten beginnt der Stop-Control-Connection-Request zunächst mit den üblichen PPTP-Feldern. Deshalb wird auch hier nur auf die neuen Felder eingegangen [12].

Quelle: [13]

Control Message Type Dieses Feld enthält den Wert 3. Dies steht für Stop-Control-Connection-Request (siehe Tabelle).

11

Reserved0, Reserved1, Reserved2 Diese Felder müssen alle 0 sein. Reason Dieses Feld gibt den Grund für das Beenden der Kontrollverbindung an. Gültige Werte sind hier:

1. (None) Eine generelle Anfrage für den Verbindungsabbau 2. (Stop-Protocol) Die Version des Protokolls wird nicht unterstützt 3. (Stop-Local-Shutdown) Der Anfragende Rechner wird heruntergefahren

Alle anderen Felder haben eine identische Bedeutung wie zuvor Vorgestellt.

Stop-Control-Connection-Reply Der Stop-Control-Connection-Reply wird von einer Seite der Verbindung gesendet, die einen Stop-Control-Connection-Request empfangen hat.

Quelle: [13]

Control Message Type Dieses Feld ist 4 für Stop-Control-Connection-Reply (siehe Tabelle). Result Code Dieses Feld entspricht dem Ergebnis des Versuches die Verbindung zu Beenden. Gültige Werte sind hier:

1. (OK) Die Kontrollverbindung wird erfolgreich beendet 2. (General Error) Die Kontrollverbindung konnte nicht beendet werden. Der Grund hierfür

wird im Error Code angegeben. Error Code Dieses Feld ist im Normalfall 0, es sei denn ein Fehler ist aufgetreten. Wenn ein Fehler eingetreten ist, so wird der Result Code auf 2 (General Error) gesetzt, und der Fehlercode in dieses Feld geschrieben. Gültige Error Codes wurden zuvor bereits vorgestellt.

Der Verbindungsauf- und -abbau

12

Quelle: [13]

Wie schon erwähnt kann die Verbindung von beiden Seiten aufgebaut werden. Dabei wird nicht zwischen Client und Server unterschieden, sondern zwischen dem der die Verbindung aufbauen möchte (Originator - Sender) und dem, der die Anfrage zum Verbindungsaufbau erhält (Receiver - Empfänger). Wir betrachten nun den Verbindungsauf- und -abbau beim Sender. Der Sender baut eine TCP-Verbindung beim Empfänger auf Port 1723 auf. Steht diese Verbindung so schickt er eine Start-Control-Connection-Request Anfrage an den Empfänger, und geht dann in eine Wartephase („wait_ctl_reply“) über. Nun wartet er auf einen Start-Control-Connection-Reply des Empfängers. Trifft dieses ein, so wird die Protokollversion im Feld „Protocol Version“ untersucht. Wird diese Version unterstützt, so ist die Verbindung aufgebaut, und der Sender wechselt in die Phase „established“. Ist die empfangene Version eine ältere als die gesendete, so wird die ältere Version (falls sie unterstützt wird) benutzt. Wird die empfangene Version nicht unterstützt, oder eine bereits bestehende Verbindung soll geschlossen werden, dann muss ein Stop-Control-Connection-Request gesendet werden, und in die Phase „wait_stop_reply“ übergegangen werden. Jetzt wird nur noch auf das Stop-Control-Connection-Reply gewartet, und dann die TCP-Verbindung beendet. Beide sind nun wieder in der Lage eine neue Verbindung aufzubauen. Es kann beim Verbindungsaufbau zu einer Kollision kommen, wenn beide also PAC und PNS gleichzeitig versuchen eine Verbindung aufzubauen. Dann öffnen beide zunächst eine TCP-Verbindung und senden den Start-Control-Connection-Request. Die Kollision wird dadurch erkannt, dass anstatt des erwarteten Start-Control-Connection-Replys ein Start-Control-Connection-Request empfangen wird (nämlich der Request des anderen). Da es nicht möglich ist zwei Kontrollverbindungen zu haben muss eine Anfrage beendet werden. Dazu wird diejenige Anfrage mit der niedrigeren IP-Adresse ausgewählt. Versuchen z.B. zwei Rechner mit den IP-Adressen 192.33.45.17 und 192.33.45.89 eine Verbindung aufzubauen, und es kommt zu einer Kollision, so erhält der letztere Rechner den Vorrang. Der erste muss nun seine TCP-Verbindung beenden ohne weitere PPTP-Nachrichten darüber zu senden. Danach muss er mit einem Start-Control-Connection-Reply dem „Gewinner“ antworten. Dieser wartet einfach solange, bis diese Antwort bei ihm eintrifft [12] Nachdem wir nun den Verbindungsauf- und -abbau untersucht haben wollen wir noch einmal kurz auf die Verbindungsaufrechterhaltung eingehen. Dazu werden zwei Nachrichten benötigt, die nun noch einmal kurz vorgestellt werden.

13

Echo-Request Diese Anfrage wird dazu benötigt, um festzustellen, ob noch eine Verbindung zwischen den beiden Rechnern besteht. Sie stellt eine so genannte „keep alive“ Anfrage da.

Quelle: [13]

Control Message Type Dieser Wert ist 5 für Echo-Request (siehe Tabelle). Identifier Dies ist ein Wert, der vom Sender der Anfrage gesetzt wird. Der Wert wird in der Antwort erneut gesendet, damit der Empfänger die Antwort zur richtigen Anfrage zuordnen kann.

Echo-Reply Der Echo-Reply wird als Antwort auf einen empfangenen Echo-Request gesendet. Dadurch wird sichergestellt, dass die Verbindung noch intakt ist.

Quelle: [15]

Control Message Type Dieser Wert ist 6 für Echo-Reply (siehe Tabelle). Identifier Dieser Wert wird aus dem zuvor empfangenen Echo-Request einfach kopiert. Dadurch wird sichergestellt, dass die Antwort zur richtigen Anfrage passt. Result Code Hier steht das Ergebnis für den empfangenen Echo-Request. Gültige Werte sind:

1. (OK) - Der Echo-Reply ist gültig. 2. (General Error) - Der Echo-Request wurde nicht akzeptiert. Der Grund dafür wird in Error

Code angegeben.

14

Error Code Dieses Feld ist im Normalfall 0, es sei denn ein Fehler ist aufgetreten. Wenn ein Fehler eingetreten ist, so wird der Result Code auf 2 (General Error) gesetzt, und der Fehlercode in dieses Feld geschrieben (siehe Fehlercodes oben). Ist eine Kontrollverbindung nicht in der Phase „established“, aber es besteht ein TCP-Verbindung, so sollte innerhalb von 60 Sekunden ein Start-Control-Connection-Request gesendet werden. Erhält eine Partei nicht innerhalb von 60 Sekunden einen Start-Control-Connection-Request oder wartet länger als 60 Sekunden auf einen entsprechenden Reply, so sollte die Kontrollverbindung geschlossen werden. Ist die Kontrollverbindung erfolgreich aufgebaut worden und eine Partei hat seit 60 Sekunden keine Kontrollnachricht mehr erhalten, sollte sie ein Echo-Request senden. Empfängt sie nach weiteren 60 Sekunden keinen entsprechenden Echo-Reply, muss die Kontrollverbindung geschlossen werden. Wie schon vorher gesehen, gibt es noch ein ganze Reihe weitere Kontrollnachrichten, auf die jedoch hier nicht weiter eingegangen werden kann. Die meisten davon werden zum Call Management benötigt [12].

Generic Routing Encapsulation (GRE) 1994 existierten bereits einige Protokolle und Requests for Comments (RFCs) zum Thema Network-Tunneling sowohl auf Layer 2 als auch auf Layer 3. Diese waren jedoch teilweise sehr spezialisiert; vor allem waren sie eingeschränkt in Art und Anzahl der Protokolle, die sie transportiern konnten. Außerdem erschien ihre Verwendung sehr aufwändig (als O(n²)-Problem [14]). Aus diesem Grunde entwarfen Mitarbeiter von NetSmith Ltd. und Cisco Systems in RFCs 1701/1702 ein Tunneling-Protokoll, das einen eher allgemeinen Character haben sollte, um einen grundlegenden Lösungsvorschlag anzubieten, der auf Spezialitäten einzelner Protokolle verzichten sollte – um den Preis, einen etwas praxisferneren Ansatz zu bieten, der sich für eine „Situation, in der eine bestimmte 'x über y'-Kapselung beschrieben ist [...] schlechter eignen könnte“ [14]. Das Ergebnis trägt den Namen Generic Routing Encapsulation (GRE), kann alle Protokolle der Schichten 2 und 3 nahezu beliebig ineinander verschachteln und führt zu folgendem Paketaufbau: ********************************************* * Transport-Header * GRE Header * Nutzlast * ********************************************* Wobei es sich beim Transport-Header um den Header des Protokolls handelt, in das eingekapselt werden soll (engl. delivery protocol) und die Nutzlast aus dem zu transportierenden Paket (payload packet) besteht.

Der GRE-Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|Recur| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Offset (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing (optional)

15

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Schema aus [14])

Der GRE-Header ist sehr modular aufgebaut. Er besteht zunächst aus vier Bits, die angeben, ob optionale Felder am Ende des Headers verwendet werden, oder nicht. Beginnend von Bit 0 an sind diese Bits: – das Checksum Present-Bit, das angibt, ob das Checksum-Feld Verwendung findet (s.u.) – das Routing Present-Bit, das angibt, ob das Routing-Feld Verwendung findet (s.u.) – das Key Present-Bit, das das Key-Feld im Header „aktiviert“. Das 32-Bittige Key-Feld kann vom

einkapselnden System verwendet werden, um sich beim Empfänger zu Authentifizieren. Die genaue Methode der Authentifizierung ist in den GRE-RFCs offen gelassen.

– das Sequence-Number-Bit, das die Verwendung der Sequenznummer signalisiert. Das Sequenznummernfeld selbst ist 32 Bit lang und dient dazu, dem Empfänger die Rekonstruktion der korrekten Reihenfolge der ankommenden Pakete zu ermöglichen.

Darauf folgt ein weiteres Bit, das das sog. Strict-Source-Routing aktiviert, was bedeutet, dass die Route, die das Paket nimmt, im vorhinein zu definieren ist – und zwar inklusive der korrekten Reihenfolge der weiterleitenden Router. Ist das Feld nicht aktiviert, und werden trotzdem Router im dafür vorgesehenen Feld (s.u) angegeben, wird Loose Source Routing eingesetzt: die Pakete müssen die Router zwar ebenfalls in der angegebenen Reihenfolge passieren, dürfen jedoch zwischendurch auch von nicht aufgeführten Routern bedient werden. Für zusätzliche, noch zu definierende Flags dieser Art sind die Bits 8 bis 12 des Headers vorgesehen. Die Bits 5-7 (Recursion Control) repräsentieren eine Integer-Zahl, die angibt, wie viele rekursive Verschachtelungen der Kapselung (Protokoll A in GRE in Protokoll B in GRE in Protokoll C...)zulässig sind. Die verwendete GRE-Versionsnummer wird in den Bits 13-15 codiert. Den Abschluss der obligatorischen Felder bildet die aus 16 Bits bestehende Angabe des transportierten Protokoll-Typs. Einige Protokoll-Kodierungen sind bereits in RFC 1701 vordefiniert (z.B. 0x0800 für IP); andere werden durch ihre von der IANA (Internet Assigned Numbers Authority) zugewiesene Nummer (z.B. 0x880B für PPP) einsetzbar – eine Aufstellung der vergebenen Nummern findet sich unter [15]. Die beiden folgenden, optionalen 16-Bit-Felder treten nur gemeinsam auf und sind vorhanden, wenn das Checksum-Present-Bit oder das Routing-Present-Bit gesetzt ist. Das erste der Felder, die Checksumme nimmt jedoch nur bei gesetztem Checksum-Present-Bit einen gültigen Wert an – analoges gilt für das sich anschließende Offset-Feld, das nur bei aktiviertem Routing einen sinnvollen Wert enthält. Die Checksumme wird aus dem (16-Bit-weisen) Einer-Komplement der Bestandteile des GRE-Headers UND der Nutzdaten gebildet. Der Offset gibt bei aktiviertem Routing an, wie viele sog. Octets (Bytes) zwischen dem Beginn des optionalen Routing-Felds und dem aktuell verwendeten Source Route Entry (s.u.) liegen.

Routing in GRE Am Ende des GRE-Headers steht das Routing-Feld, das aus einer variablen Anzahl von Source Route Entries (SREs) besteht. Source Routing ist ein Verfahren, das ursprünglich in Shared Media-Netzen verwendet wurde, bei dem die Komplette Route des Paketes (oder des Frames, wobei es korrekterweise Source Route Bridging heißen müsste) vom Sender vorbestimmt wird, der deshalb – im Gegensatz zu anderen Routing-Verfahren – Informationen über die Netzinfrastruktur selbst vorhalten muss. Es gibt jedoch auch Varianten dieses Verfahrens, bei dem Teile der Route

16

dynamisch bestimmt werden können. Jeder SRE im Header besteht aus vier Feldern: Zunächst werden in einem 32 Bit langen Address Family-Feld „Syntax und Semantik“ [14] des Routing Information Fields (RIF) definiert. Das zweite, 8 Bittige Feld SRE Offset gibt die Position des aktuellen Eintrags in Relation zum Beginn des RIF an; weitere 8 Bit im SRE Length-Abschnitt enthalten die Gesamtlänge des RIF. Das RIF selbst ist durch das Address Family-Feld definiert und von variabler Länge. Seine Struktur hängt sehr stark vom transportierenden Protokoll ab. Findet das Routing z.B. durch ein IP-Netz statt, besteht es aus einer Liste von IP-Adressen, an die das Paket nacheinander weitergeleitet werden soll. Dazu werden mithilfe des stetig nachgeführten globalen Zeigers im Offset-Feld des GRE-Headers nacheinander alle SREs abgearbeitet, und in ihnen nacheinander unter Verwendung des lokalen SRE-Offsets die einzelnen Zieladressen ausgewählt. Sind beide Zeiger am letzten vorhandenen Element angelangt, ist der letzte der vorgegebenen Router erreicht, der die Zustellung zum Zielsystem vornimmt, indem er den GRE-Header entfernt und das Nutzlastpaket auf die übliche Weise zustellt. [5][14][15][16]

Der erweiterte GRE-Header Wir haben bereits den standard GRE-Header kennen gelernt. PPTP benutzt einen leicht modifizierten GRE-Header, der im Folgenden kurz vorgestellt werden soll. Es wird jedoch nur auf die Unterschiede zwischen den beiden Varianten eingegangen.

Quelle: [13]

Die folgenden Angaben sind speziell für PPTP gültig. Die ersten beiden Bits (das Checksum Present Bit und das Routing Present Bit) werden auf 0 gesetzt. Das Key Present Bit wird auf 1 gesetzt. Das Sequence Number Present Bit ist abhängig vom Inhalt des Pakets. Ist es ein Daten-Paket wird es auf 1 gesetzt für ein Acknowledgment-Paket (keine Daten vorhanden) wird es auf 0 gesetzt. Das Strict Source Route Present Bit wird auf 0 gesetzt, und die Recursion Control ist ebenfalls 0. Das nächste Bit ist speziell für PPTP eingefügt worden. Es ist das sogenannte Acknowledgment Sequence Number Present Bit. Dieses Bit wird auf 1 gesetzt, wenn das Paket eine Acknowledgment Nummer enthält, die benutzt wird um vorher empfangene Daten zu bestätigen. Die anderen Flags werden auf 0 gesetzt. Die Version muss eine 1 enthalten, was für „enhanced GRE“ steht. Der Protocol Type wird auf 0x880B (Hexadezimal) gesetzt. Nun folgt im standard GRE-Header das Key Feld, welches bei PPTP in folgende Elemente aufgeteilt ist: Der Payload Length (die oberen 2 Oktetts vom Key Feld) enthält die Größe der Nutzdaten jedoch ohne den GRE-Header. Das Call ID Feld (die unteren 2 Oktetts vom Key Feld) enthält die Call ID des PNS bzw. des PACs für die Session zu dem dieses Paket gehört.

17

Das nächste Feld enthält die Sequenznummer sofern eine vorhanden ist (Sequence Number Present Bit muss gesetzt sein). Darauf folgt die Acknowledgment Nummer des höchsten bisher empfangenen Pakets sofern diese vorhanden ist [12]. Die Sequenznummern die hier auftreten sind pro Paket zu verstehen. Sie werden für jede Session einzeln festgelegt. Bei einer neuen Session wird die Sequenznummer auf 0 gesetzt. Jedes erstellte Paket, welches mit einer Sequenznummer ausgestattet wird bekommt die nächst mögliche Nummer aufsteigend zugewiesen.

Sicherheit Im Bezug auf die Sicherung der Übertragung muss zwischen der Authentifizierung des Benutzers (bzw. des von ihm verwendeten Client, auch Peer genannt) gegenüber dem Server (Authenicator) und der Verschlüsselung des eigentlichen Datenverkehrs unterschieden werden. Im „klassischen“ PPP-Anwendungsfall, dem Dialup-Peer-To-Peer-Netz, bei dem eine direkte 1:1 Verbindung zwischen zwei Rechnern über eine Wählleitung hergestellt wird ist das Abhören der Verbindung verhältnismäßig aufwändig, weil leitungsvermittelt gearbeitet wird und deshalb Ressourcen exklusiv zugewiesen werden. Ein möglicher Angreifer muss sich also zunächst in das Medium „einklinken“. Aus diesem Grund spielt die Authentifizierung bei PPP natürlicherweise eine wichtigere Rolle. Es muss primär vermieden werden, dass es unbefugten dritten gelingt, sich bei den eigenen Systemen anzumelden. Der Transport von PPP über ein Ether- oder Internet stellt jedoch ganz neue Anforderung an beide Sicherheitsmechanismen, da hier die Angriffsmöglichkeiten ungleich vielfältiger und mit weniger Aufwand umzusetzen sind. PPTP sieht keine eigenen Methoden zur Benutzerauthentifizierung und Datenverschlüsselung vor. Es werden stattdessen die bereits für PPP vorgesehenen Methoden verwendet.

Authentifizierung Die Authentifizierung findet beim PPP-Verbindungsaufbau in der Phase zwischen der Aushandlung der Layer-2-Parameter über LCP und der Vorbereitung des Layer-3-Protokolls über NCP statt. Zur Authentifizierung werden in RFC 1334 zwei Verfahren angeboten (was jedoch den Einsatz anderer Methoden nicht ausschließt): Das Password Authentication Protocol (PAP) und das Challenge Handshake Authentication Protocol (CHAP). Letzteres wird mit RFC 1994 aus dem Jahr 1996 zum Internet Standard erhoben; RFC 1334 mitsamt PAP wurde zu diesem Zeitpunkt obsolet. Der Vollständigkeit halber, und weil PAP in der Praxis immer noch eine Rolle spielt, soll es hier jedoch ebenfalls beschrieben werden:

PAP PAP beschreibt eine einfache Methode um einen Peer bei seinem Authenticator anzumelden. PAP arbeitet ohne echte Verschlüsselung und überträgt sämtliche Daten im Klartext. Ziel der Entwicklung war es, den Login eines Benutzers bei einem Remote-Host zu simulieren und ein dem vergleichbares Sicherheitsniveau zu erreichen. PAP Pakete werden jeweils im Verhältnis 1:1 in einem PPP-Frame transportiert. Dazu wird im PPP-Frame der Pakettyp 0xC023 angegeben. Es existieren drei verschiedene Arten von PAP-Paketen. Der PAP-Header ist in allen Varianten identisch: ********************************************* (Der PAP-Header) * Paketart (8-Bit) * Identifier (8 Bit) * Länge (16 Bit) * ********************************************* * „Nutzdaten“ (variabel) * *********************************************

18

Im ersten Feld wird die Art des PAP Paketes wie folgt codiert: 1 – Authentifizierungs-Anforderung (Authenticate-Request) 2 – Authentifizierungs-Bestätigung (Authenticate-Ack) 3 – Authentifizierungs-Ablehnung (Authenticate-Nak) Der Identifier dient lediglich dazu, gesendete und darauf bezogene empfangene Pakete einander zuordnen zu können; die Länge bezieht sich auf das gesamte Paket inkl. Header und Datenanteil. Die Authentifizierungs-Anforderung muss vom Peer gesendet werden, um die Authentifizierung zu starten. Die Sendung wird so lange wiederholt, bis eine Antwort eintrifft, oder die Verbindung getrennt wird. Das entsprechende Paket wird um vier Felder erweitert: jeweils zwei variabler Größe für Peer-ID und Passwort, deren Länge in ihnen jeweils vorangestellen 8-Bit-Feldern angegeben wird. ID und Passwort können auch leer sein. Wie bereits erwähnt erfolgt die Übertragung im Klartext, doch wird empfohlen, aus dem Passwort einen Einmalschlüssel zu generieren und stattdessen diesen zu übertragen (vgl. CHAP). Trifft eine Authentifizierungs-Anforderung beim Authenticator ein, verifiziert dieser die empfangenen Daten und sendet in jedem Fall eine Antwort zurück – eine Bestätigung oder Ablehnung. Für den Fall, dass eine positive Antwort verloren geht und der Peer deshalb weiterhin Anforderungen stellt, muss der Authenticator in der Lage sein, seine Antwort zu wiederholen, bevor er in die nächste Phase des Verbindungsaufbaus eintritt. Geht ein Authenticate-Nak verloren, hat der Peer den Verbindungsabbau (über LCP) durch den Authenticator als Ablehnung zu werten. Die Authenticate-Ack oder -Nak Pakete müssen keine weiteren Informationen enthalten, können jedoch um eine (nach Empfehlung des RFC menschenlesbare) Nachricht ergänzt werden, die aber keine Auswirkungen auf die Funktionsweise des Protokolls haben darf.

Sicherheitsprobleme bei PAP Als Kritik am PAP Verfahren lässt sich – abgesehen von der bereits erwähnten fehlenden Verschlüsselung der Benutzerdaten – sagen, dass die Frequenz und Anzahl der Authentifizierungsversuche vom Peer bestimmt wird. Es gibt keinerlei Mechanismus, der massives Ausprobieren (Brute-Force-Angriff) des Passworts verhindern könnte. [17]

CHAP Die größten Sicherheitsprobleme von PAP werden im zeitgleich veröffentlichten CHAP-Protokoll (Protokoll-Nummer 0xC223) behoben: CHAP verlegt die Kontrolle über die Authentifizierung in die Hand des Authenticators und verwendet einen 3-way handshake mit einem Challenge-Response-Verfahren, um kein Passwort übertragen zu müssen. Dies bedeutet: Authenticator und Peer haben sich im Vorhinein auf ein sog. Geheimnis (Passwort) geeinigt, welches im Klartext vorliegt. Während der PPP-Authentifizierungsphase sendet der Authenticator dem Peer eine sog. Challenge. Dabei handelt es sich um einen zufälligen Wert, den der Peer seinerseits mit dem ihm bekannten Geheimnis in einem Ein-Wege-Verfahren zu einem Hashwert verrechnet und zum Authenticator zurück sendet. Das einzige Hashing-Verfahren, dessen Implementierung der in [19] definierte Standard zwingend voraussetzt ist MD5. Aus dem gebildeten Hashwert lässt sich das Geheimnis nicht rekonstruieren. Der Authenticator vollzieht

CHAP

19

unterdessen die Bildung des Hashwertes nach und vergleicht die Antwort des Peers mit dem eigenen Ergebnis. Stimmen die beiden Werte überein, wird die Authentifizierung bestätigt und der Verbindungsaufbau wird fortgesetzt. Andernfalls sollte der Authenticator die Verbindung sofort beenden. Dieser Authentifizierungsprozess kann während des Bestehens der Verbindung in zufälligen Zeitabständen wiederholt werden (natürlich mit einer jeweils anderen Challenge). Auf diese Weise soll die Zeit, welche die Verbindung einem Angriff jedweder Art ausgesetzt ist, limitiert werden [18]. Die Kommunikation auf Paketebene verläuft bei CHAP und PAP sehr ähnlich. Der Hauptunterschied ist, dass die Authentifizierungsanforderung (die Response) in CHAP erst auf Aufforderung durch den Authenticator gesendet wird und letztere unter Umständen später wiederholt wird. Auch der Aufbau des CHAP-Headers entspricht in seiner Grundform der des PAP-Headers (s.o.). CHAP kennt vier Paketarten: 1 – Challenge („Authentifizierungs-Aufforderung“) 2 – Response (Analog zum Authenticate-Request) 3 – Success (Analog zum Authenticate-Ack) 4 – Failure (Analog zum Authenticate-Nak) Die Challenge und Response Pakete sehen im Nutzdatenteil den Transport dreier Felder vor: eine 8-Bit Value-Size gibt die Länge des darauf folgenden Value-Feldes an. In diesem steht die Challenge bzw. der Response-Hashwert. Auf ihn folgt ein Feld variabler Länge (dessen Größe aus der Gesamtlängenangabe im Header berechnet werden kann) für die zugehörige Benutzer-ID. Die Success und Failure Pakete verhalten sich analog zu ihren PAP-Pendants.

CHAP-Sicherheitsprobleme Ein großer Unsicherheitsfaktor in CHAP liegt in der Implementierung. Der Standard gibt eine Reihe von Hinweisen auf mögliche Sicherheitsrisiken. Ein Problem ist, dass das Geheimnis im Klartext vorliegen muss. Bei größeren Infrastrukturen, bei denen eine Anmeldung bei mehreren verschiedenen Authenticators notwendig ist, ist dieses Risiko noch erhöht – in solchen Fällen wird das Geheimnis oft auf einem zentralen Server gespeichert, der für alle potenziellen Authenticators erreichbar ist – in diesem Fall muss dafür gesorgt werden, dass wiederum die Verbindung zwischen besagtem Server und den einzelnen Authenticators abgesichert wird. Hinzu kommt, dass das Geheimnis beiden Seiten bekannt sein und deshalb zumindest einmal auf sicherem Wege transportiert werden muss. Zudem findet beim beschriebenen Vorgang eine Ein-Wege-Authentifizierung statt – nur die ID des Peers wird gegenüber dem Authenticator geprüft – ein Angreifer könnte sich also als Authenticator ausgeben, die Response des Peers ungeprüft akzeptieren und so zum Beispiel vom Peer gesendete potenziell sensible Daten mithören. Um dies zu vermeiden muss eine bidirektionale Authentifizierung stattfinden. Zu diesem Zweck muss nicht zwangsläufig in beide Richtungen dasselbe Protokoll eingesetzt werden. Wird dennoch für beide Authentifizierungen CHAP eingesetzt, ist es wichtig, nicht beide Male dasselbe Geheimnis zu verwenden – ansonsten könnte ein Angreifer die empfangene Challenge einfach als die eigene zurücksenden, und sich mit der daraufhin erhaltenen Antwort selbst authentifizieren. 2004 wurde ein analytisches Verfahren entwickelt, mit dem im verwendeten MD5-Hashing-Algorithmus (Message Digest Algorithm 5) Kollisionen gefunden werden können. Kollisionen sind verschiedene Eingabewerte, die zum gleichen Hashwert führen. Daraus folgt keine unmittelbare Sicherheitslücke, sofern man nur den Hashwert kennt – dennoch erhöht sich die Wahrscheinlichkeit, das Passwort zu erraten. [18][19][20][21]

20

MS-CHAP-V2 1998 wurde CHAP von Microsoft in RFC 2433 erweitert, um Kompatibilität mit bestehenden Microsoft-Produkten sicherzustellen. Unter anderen Erweiterungen, wie zum Beispiel der protokollseitigen Unterstützung einer Passwortänderung, wurde vor allem dafür gesorgt, dass die Speicherung des Passworts in unverschlüsselter (oder entschlüsselbarer) Form unnötig ist [22]. Im Jahr 2000 wurde Version 2 unter dem Kürzel MS-CHAP-V2 veröffentlicht [23]. Das Verfahren erfreut sich – vor allem in Netzen mit Windows-Anteil – auch heute noch großer Beliebtheit und ist – bedingt durch den hohen Verbreitungsgrad von Microsoft-Produkten – das bei PPTP meisteingesetzte Verfahren, weswegen es hier gesondert betrachtet werden soll. MS-CHAP-V2 funktioniert ebenfalls nach dem Challenge-Response-Verfahren, ist jedoch weitaus aufwändiger, dafür garantiert es jedoch eine bidirektionale Authentifizierung. Im folgenden wird anstelle von Authenticator und Peer auch von Server und Client gesprochen, um eine Begriffsverwirrung in Anbetracht der gegenseitigen Authentifizierung zu vermeiden. Das Verfahren besteht aus 6 Schritten [24]: 1. Der Client fordert die Zusendung einer Challenge

beim Server an. 2. Der Server antwortet mit einer 16 Byte langen

(zufälligen) Authenticator Challenge (AC) 3. Der Client generiert seine Response wie folgt:

a) Erstellen einer 16 Byte langen, zufälligen Peer Challenge (PC)

b) Generierung eines Hash-Wertes (der späteren Challenge für die Authentifizierung des Servers) mittels des SHA-Verfahrens aus AC, PC und der Benutzerkennung (UID). „Abschneiden“ des Ergebnisses nach 8 Bytes.

c) Generierung eines NT-Password-Hash-Wertes (PWH) aus dem Windows-NT-Benutzer-Passwort.

MS-CHAP-V2: Schritt 3

d) Auffüllen des (16 Byte langen) PWH mit fünf „0“-Bytes, um eine Länge von 21 Bytes zu erreichen. Danach Bildung dreier jeweils 7 Byte langen DES-Keys aus dem Ergebnis.

e) Die aus (b) resultierende Challenge wird mit jedem der drei in (d) generierten DES-Keys verschlüsselt.

f) Die in (e) fertig gestellte Challenge, die PC und die UID werden an den Server übermittelt. 4. Der Server entschlüsselt die Antwort. Dazu benötigt er nur noch den PWH, also den aus dem

Geheimnis gebildeten Hashwert, der ihm in einer Datenbank vorliegt. 5. Ist der Vergleich des Ergebnisses mit der AC erfolgreich, antwortet der Server mit einem

Acknoledgement, mit dem er sich selbst gleichzeitig selbst Authentifiziert: a) Aus dem dem Server vorliegenden PWH wird mithilfe von MD4 erneut ein Hashwert

(Password-hash-hash, PWHH) gebildet. b) Ein weiterer Hashwert wird mittels SHA aus dem PWHH, der Empfangenen Antwort und der

Zeichenkette „Magic server to client signing constant“ generiert. c) Aus den resultierenden 20 Bytes wird zusammen mit der vom Client erhaltenen Challenge

und der Zeichenkette „Pad to make it do more than one interation“ durch SHA ein dritter Hashwert gebildet.

d) Das Ergebnis aus (c) wird dem Client übermittelt 6. Der Client vollzieht diesen Vorgang nach und vergleicht sein eigenes mit dem vom Server

21

empfangenen Ergebnis. Die gegenseitige Authentifizierung ist abgeschlossen.[22][23][24]

Sicherheitsprobleme in MS-CHAP-V2 Das Vorgehen in Microsofts Protokoll ist trotz des hohen Aufwandes und der vielfältigen durchgeführten Berechnungen keineswegs sicher. Die Response des Clients wird aus RC, PC und Benutzernamen mittels eines offenliegenden Verfahrens gebildet und vor der Übertragung veschlüsselt. Da alle Komponenten der Challenge zuvor oder anschließend unverschlüsselt über das Netz übertragen werden, stellt die Verschlüsselung mittels DES die einzige wirksame Sicherheitsmaßname dar. Doch auch diese birgt Probleme in sich: durch das Auffüllen des Passwort-Hashes mit fünf bekannten, immer gleichen Bytes und das anschließende Aufteilen des Ergebnisses in 3 DES-Keys á 7 Bytes sorgt dafür, dass der dritte entstehende Schlüssel effektiv aus lediglich zwei Bytes besteht. Auf diese Weise können mittels Brute-Force in sekundenschnelle die letzten 16 Bit des Ursprünglichen Hash-Wertes bestimmt werden. Die Eigenschaft der Hashfunktion, gleichverteilte Werte zu erzeugen, hilft, durch die Kenntnis dieser 16-Bit die Anzahl der möglichen Hashwerte und damit die Anzahl der möglichen Geheimnisse um den Faktor 216 reduziert. Da es sich bei den Geheimnissen um Windows-NT-Passwörter handelt, kommt hinzu, dass der Zeichenvorrat, aus dem es bestehen kann sowie seine wahrscheinliche Länge begrenzt sind. Hier gelten natürlich die gängigen Regeln für Passwort-Sicherheit. Nimmt man an, dass ein Passwort aus 8 Zeichen besteht, und der Zeichenvorrat, aus dem es gebildet wurde, neben den großen und kleinen Buchstaben noch 43 Ziffern und Sonderzeichen (also insgesamt 95 Zeichen) umfasst, kommt man auf eine Gesamtzahl von ca. 252 möglichen Passwörtern. Durch Anwendung des durch den beschriebenen Angriff erworbenen Wissens reduziert sich diese Zahl auf 236. Diese Anzahl an Passwörtern ist auch auf langsamen Systemen binnen weniger Tage auszuprobieren. Hinzu kommt, dass für das verwendete MD4-Verfahren bekannt ist, dass es noch weitaus Kollisionsunbeständiger ist, als MD5. [20][24][25][26]

Verschlüsselung

PPP Encryption Control Protocol (ECP) und DESE Die Mechanismen zur Verschlüsselung werden in PPP nach Abschluss der LCP-Leitungsvorbereitungsphase und der Authentifizierung ausgehandelt. Grundsätzlich ist der Einsatz beliebiger Verschlüsselungsverfahren und die Benutzung verschiedener Algorithmen für beide Richtungen möglich. PPP-Verschlüsselungsverfahren chiffrieren den kompletten PPP-Frame samt Header. Der Frame wird anschließend über ein Verschlüsselungsprotokoll transportiert, welches wiederum in PPP verpackt wird. Um zu bestimmen, welches Verschlüsselungsprotokoll mit welchen Parametern und Algorithmen Verwendung finden soll, wird ECP (PPP-Protokolltyp: 0x0053) eingesetzt. ECP-Pakete ähneln in ihrem Aufbau den LCP-Paketen; de facto handelt es sich auch um solche mit einigen Modifikationen und Erweiterungen. Der wichtigste Teil des ECP-Headers ist die Angabe des Verschlüsselungsprotokolltyps. Im ECP-Standard wurde zunächst nur ein Protokoll vorgesehen und in RFC 1969 beispielhaft beschrieben. Dabei handelt es sich um das PPP DES Encryption Protocol (DESE). Die Implementierung anderer Protokolle stellt aber kein Problem dar. Für alle neuen Protokolle muss jedoch eine Protokollnummer bei der IANA beantragt werden, die dann im transportierenden PPP-Frame eingetragen werden muss. Für Firmen, die keine solche Nummer reservieren, trotzdem aber proprietäre Lösungen entwickeln wollen, existiert in ECP ein Organisationally Unique Identifier (OUI). Wird diese Option gewählt, trägt man im Protokollfeld des PPP-Headers die höchstwertigen drei Bytes der IEEE-802-Hardware-Adresse (MAC) ein, die dem jeweiligen Hersteller eindeutig zugeordnet ist. DESE wiederum verwendet nur einen der Kryptographie-Modi des symmetrischen

22

Kryptographieverfahrens Data Encryption Standard (DES), nämlich den Cipher Block Chaining mode (CBC). Dazu wird, wie in allen andern DES-Modi auch ein 56-Bit Geheimnis (Schlüssel von 64 Bit inkl. 8 Bit Parität) verwendet, das wie üblich auf nicht näher definiertem Wege allen Beteiligten bekannt gemacht werden muss. Die Verschlüsselung findet, wie in DES üblich, blockweise in 64-Bit-Blöcken (mithilfe eines Permutationsverfahrens) statt, wobei vor der Verschlüsselung jedes einzelnen Blocks das Chiffrat seines jeweiligen Vorgängers auf seinen Klartext addiert wird. So werden die Blöcke untereinander verkettet – auf diese Weise erfordert ein Angriff auf die Kommunikation weitaus mehr Aufwand, als in einem kontextunabhängigen Verfahren. Da der erste Block natürlicherweise keinen Vorgänger hat, übernimmt die Rolle des „nullten Blocks“ ein (zufällig zu bestimmender) Initialisierungsvektor, der in der ECP-Phase übermittelt wird. Um es zu ermöglichen, dass sich einzelne Blöcke auch über Paketgrenzen hinweg erstrecken können, sieht der DESE-Header eine 16-Bit Sequence Number vor, um sicherzustellen, dass die Reihenfolge der Blöcke nachvollziehbar bleibt.

Sicherheitsprobleme in DES(E) Wie bereits im Zusammenhang mit MS-CHAP-V2 gezeigt, birgt das sogenannte „Padding“, also die künstliche Verlängerung von Bytefolgen auf eine benötigte Länge einige Sicherheitsrisiken in sich. Am Beispiel war bereits zu sehen, dass DES nicht mit Blöcken von weniger als 64 Bit umgehen kann. Wird Padding betrieben, muss also eine intelligente Implementierung vorliegen, die z.B. mit zufälligen Bytefolgen und sinnvoll gewählten Wahrscheinlichkeitsverteilungen einzelner Bytes arbeitet. Auch die geringe Schlüssellänge in DES (das sich übrigens im Bankensektor nach wie vor einer großen Beliebtheit erfreut) stellt ein Problem dar, da die Zahl der möglichen Schlüssel sehr begrenzt ist und mit steigender Rechenleistung moderner Computer in immer kürzerer Zeit durchprobiert werden kann. „Vorsichtige“ Gemüter weisen auch darauf hin, dass der US-Inlandsgeheimdienst NSA an der Entwicklung von DES einen großen Anteil hatte, und man aus diesem Grund niemals völlig sicher sein könne, ob dem Verfahren zu Trauen ist. Alles in allem sollte also von der Verwendung von DES(E) zugunsten moderner Verfahren mit größeren Schlüssellängen abgesehen werden. [28] [29] [32]

RC4 RC4 (Rivest Cipher 4) ist ein Stromchiffrieralgorithmus, der Byteweise durch XOR-Vergleich verschlüsselt. Er wird zum einen bei WLAN für WEP genutzt, ist zum anderen auch im Einsatz mit PPTP sehr verbreitet, vor allem, weil es sich um den von Microsoft präferierten Algorithmus handelt, der in Windows NT bereits als Standard implementiert ist. Zur Verschlüsselung wird zunächst (initialisiert durch ein Passwort) ein zufälliger Zeichenvorrat, die sogenannte S-Box generiert, deren Zeichen in einer aus dem Passwort errechneten Reihenfolge mit den Klartextzeichen verrechnet werden. Die S-Box ändert sich währenddessen kontinuierlich. Der Empfänger vollzieht den Vorgang der Schlüsselgenerierung nach und erhält so dieselbe Folge an Zufallswerten, mit der das Chiffrat wieder entschlüsselt werden kann. RC4 ist im Verhältnis zu anderen Verfahren schnell und in Software mit wenig Aufwand zu implementieren. Verschiedene Schlüssellängen werden unterstützt. In den Microsoft-Implementierungen für PPTP werden Längen von 40 Bit (gilt heutzutage als unsicher) und 128 Bit verwendet. Mittlerweile wurde nachgewiesen, dass im RC4-Verfahren einige Schwächen existieren – vor allem gibt es unsichere Schlüssel, sodass man bei RC4 nicht mehr von einem für Sensible Kommunikation geeigneten Verfahren sprechen kann [31] [30].

23

Zusammenfassung Wir haben die wichtigsten Technologien im Zusammenhang mit PPTP und den Aufbau und die Funktionsweise des Protokolls selbst kennen gelernt. Die wichtigsten Protokollheader und Mechanismen zum Verbindungsmanagement, zur Verschlüsselung und Authentifizierung sowie das allgemeine Tunneling-Verfahren wurden erörtert. Es wurde auch auf Sicherheitsfragen und Risiken bei der Verwendung verbreiteter Implementationen des Protokolls eingegangen.

Quellen: [1] Zeev.com http://www.zeev.com/Inter/nrpptp.htm[2] Microsoft FAQ http://www.microsoft.com/ntserver/ProductInfo/faqs/PPTPfaq.asp[3] http://de.wikipedia.org Begriff “Point-to-Point Tunneling Protocol” [4] http://www.itwissen.info (Netzwerke=>Internetzwerke=>Tunneling) [5] Andrew S. Tanenbaum, „Computernetzwerke“, 4., überarb. Auflage, Pearson Studium 2003 [6] http://de.wikipedia.org Begriff „PPP“ vom 7.7.05 [7] Bild von http://www.improve-mtc.de/Veroffentlichungen/VPN-CW/vpn-cw.html[8] Elektronik-Kompendium.de http://www.elektronik-kompendium.de/sites/net/0906141.htm[9] Zeev.com http://www.zeev.com/Inter/nrpptp.htm[10] Poptop, ein PPTP Server für Linux http://www.poptop.org/[11] PPTP Client, ein Linux Klient für PPTP http://pptpclient.sourceforge.net/[12] Hamzeh et al. : RFC 2637 : Point-To-Point-Tunneling-Protocol (www.ietf.org) [13] Eigenes Bild nach Vorlage aus Point-to-Point Tunneling Protocol RFC 2637 [14] Hanks et al.: RFC 1701/1702: Generic Routing Encapsulation [over IP4 netw.](www.ietf.org) [15] iana Ether-Types: http://www.iana.org/assignments/ethernet-numbers[16] www.zdnet.de (Glossar=>Datenkommunikation=>Protokolle=>Routing P.=>Source Routing) [17] Lloyds/Simpson: RFC 1334: PPP Authentication Protocols (www.ietf.org) [18] W. Simpson: RFC 1994: PPP Challenge Handshake Authentication Protocol (www.ietf.org) [19] http://de.wikipedia.org Begriff „CHAP“ vom 10.7.05 [20] http://de.wikipedia.org Begriff „MD5“ vom 10.7.05 [21] R. Rivest: RFC 1321: The MD5 Message-Digest Algorithm (www.ietf.org) [22] Zorn/Cobb: RFC 2433: Microsoft PPP CHAP Extensions (www.ietf.org) [23] G. Zorn: RFC 2759: Microsoft PPP CHAP Extensions Version 2 (www.ietf.org) [24] Jochen Eisinger: „Exploiting known security holes in Microsoft's PPTP Authentication Extensions (MS-CHAPv2)“, Universität Freiburg, 23.7.2001 [25] R.Rivest: RFC 1320: The MD4 Message-Digest Algorithm (www.ietf.org) [26] http://de.wikipedia.org Begriff „MD4“ vom 11.7.05 [28] G.Meyer: RFC 1968: The PPP Encryption Control Protocol (www.ietf.org) [29] Sklower/Meyer: RFC 1969: DES Encryption Protocol (www.ietf.org) [30] http://de.wikipedia.org Begriff „RC4“ vom 12.7.05 [31] http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf (Schwächen von RC4) [32] http://de.wikipedia.org Begriff „DES“ vom 28.7.05

24