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

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 (PointtoPoint 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 PPPFrames, denen ein Header des Tunneling-Protokolls
Layer 2 Tunneling [4]
3
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 IPLayer 3 Tunneling [4]
Nutzdatenfeld das „eigentliche“ Datenpaket
entnommen, welches jetzt anhand der in ihm erhalten
gebliebenen Adressierung problemlos im Zielnetz zugestellt werden kann.
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 UniNetz ü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-PunktVerbindungen, 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-zuPunkt-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
Tunneling zwischen zwei LANs [7]
4
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
Start-Control-Connection-Reply
Stop-Control-Connection-Request
Stop-Control-Connection-Reply
Echo-Request
Echo-Reply
1
2
3
4
5
6
Call Management
Outgoing-Call-Request
Outgoing-Call-Reply
Incomming-Call-Request
Incomming-Call-Reply
Incomming-Call-Connected
Call-Clear-Request
Call-Disconnect-Notify
7
8
9
10
11
12
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-ControlConnection-Request. Er beinhaltet einen Statuscode, der das Ergebnis des
Verbindungsaufbauversuches repräsentiert. Im folgenden werden nur die unterschiede des StartControl-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.
2.
3.
4.
5.
Verbindungsaufbau erfolgreich
General Error – Der Error Code gibt den aufgetretenen Fehler an
Der Kanal existiert bereits
Der Anfragende ist nicht authentifiziert für einen Verbindungsaufbau
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.
1.
2.
3.
4.
(None) – Es ist kein Fehler aufgetreten
(Not-Connected) – Es existiert noch keine Kontrollverbindung zwischen Client und Server
(Bad-Format) – Die Länge oder der Magic Cookie sind nicht korrekt
(Bad-Value) – Einer der Felder war zu Groß, oder ein Reserved-Feld war nicht 0
(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 StopControl-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 StopControl-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 StopControl-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 TCPVerbindung 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 TCPVerbindung und senden den Start-Control-Connection-Request. Die Kollision wird dadurch
erkannt, dass anstatt des erwarteten Start-Control-Connection-Replys ein Start-Control-ConnectionRequest 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-ControlConnection-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 GREHeaders 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 MediaNetzen 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 DatenPaket 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 CHAPProtokoll (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-ResponseVerfahren, 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 PPPCHAP
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
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 PAPHeaders (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 8Bit 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-HashingAlgorithmus (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.
MS-CHAP-V2: Schritt 3
c) Generierung eines NT-Password-Hash-Wertes
(PWH) aus dem Windows-NT-Benutzer-Passwort.
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 LCPLeitungsvorbereitungsphase 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 ECPHeaders 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