masterthesis/MA-Inhalt.tex

\chapter{Einleitung} \label{cpt:introduction}
Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten 3 Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.

Vor diesem Hintergrund findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55 Gbit/s im August 2017 auf etwa 85 Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.

Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
Damit ist die Voraussetzung gegeben, um Netzwerkgeräte für IPv6 zu konfigurieren und bestehende Netzwerkdienste auch über IPv6 anzubieten.

Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.
\newpage
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}


\chapter{Netzarchitektur der Abteilung Informatik} \label{cpt:netarchitecture}
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere virtuelle Netze (VLANs) unterteilt wird.
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen ist in Abbildung~\ref{fig:topology_simple} zu sehen.
\begin{figure}[ht]
\centering
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
\frame{\includegraphics[trim=75 540 75 75,clip,width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}}
\caption{Skizze der Netztopologie der Abteilung Informatik}
\label{fig:topology_simple}
\end{figure}


\section{Firewallkonzept} \label{sct:firewall}
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
Im Rahmen dieser Arbeit sind die folgenden Zonen relevant:

\paragraph{Internet}
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover.
Verbindungen in das Internet sind aus allen Zonen außer der DMZ erlaubt.
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.

\paragraph{DMZ}
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.

\paragraph{Mitarbeiter-Netz}
Die Rechner aller Mitarbeiter der Abteilung Informatik sind an dieses Netz angeschlossen.
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Pool-PC-Netz}
Enthält die Rechner aus allen Poolräumen.
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Labor-Netze}
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.

Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.

\begin{table}[ht]
\centering
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
\begin{tabular}{ *{6}{|l}| }
\hline
 & \multicolumn{5}{c|}{\dots in die Zone \dots} \\
Aus der Zone \dots & Internet & DMZ & Mitarbeiter-Netz & Pool-PC-Netz & Labor-Netze \\
\hline
Internet			& --- 	& erlaubt	& verboten	& verboten	& verboten	\\
DMZ					& verboten	& ---	& verboten	& verboten	& verboten	\\
Mitarbeiter-Netz	& erlaubt	& erlaubt	& ---	& erlaubt	& erlaubt	\\
Pool-PC-Netz		& erlaubt	& erlaubt	& erlaubt	& ---	& erlaubt	\\
Labor-Netze			& erlaubt	& erlaubt	& erlaubt	& erlaubt	& ---	\\
\hline
\end{tabular}
\label{tab:firewall_zone_access}
\end{table}


\chapter{Anforderungsanalyse} \label{cpt:requirements}
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftraggeber und Erstprüfer dieser Arbeit ermittelt wurden.

\begin{enumerate}[label=Anf\arabic*]
\item \label{req:dualstack} \textbf{Dual-Stack-Betrieb:} Der VPN-Dienst soll aus dem Internet über IPv4 und IPv6 erreichbar sein und auch innerhalb des VPN diese beiden Protokolle anbieten.
\item \label{req:routing} \textbf{VPN-interner Datenverkehr:} Nur die internen Netzbereiche der Abteilung Informatik sollen für Benutzer über das VPN erreichbar sein.
Das betrifft alle Sicherheitszonen außer dem Internet.
\item \label{req:traffic} \textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
\item \label{req:users} \textbf{Benutzer:} Der VPN-Dienst soll von autorisierten Mitarbeitern und Studenten aus der Abteilung Informatik benutzt werden können.
Die Benutzer des VPN-Dienst sollen durch die Administratoren des VPN-Dienst einfach verwaltet werden können.
\item \label{req:serveros} \textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienst soll auf einer aktuellen Version von Debian (9 oder höher) betrieben werden.
\item \label{req:clientos} \textbf{Betrieb der VPN-Clients:} Die VPN-Clientsoftware soll für aktuelle Versionen gängiger Betriebssysteme zur Verfügung stehen.
Darunter fallen Microsoft Windows 10 (Version 1709 oder höher), Apple MAC OS (ab Version 10.13) und Linux-Distributionen (ab Kernel Version 3.10).
\item \label{req:logging} \textbf{Betriebsprotokoll:} Während des Betrieb des VPN-Dienst sollen keine Daten protokolliert werden, die Rückschlüsse auf das Benutzerverhalten zulassen. Im Rahmen einer laufenden Fehlersuche soll es möglich sein, mehr Daten zu protokollieren.
\item \label{req:finance} \textbf{Finanzieller Rahmen:} Es stehen keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung.
\end{enumerate}

Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
Die Clientkomponenten der gesuchten Software müssen unter den aktuellen Betriebssystemen lauffähig sein (\ref{req:clientos}).

Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass in der gesuchten Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet werden.
Deshalb soll Kerckhoffs' Prinzip bei der Wahl der VPN-Software angewendet werden, indem ausschließlich 
quelloffene Software berücksichtigt wird.
Jedermann kann öffentlich lesbaren Quellcode auf mögliche Sicherheitslücken untersuchen; dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden.
Außerdem werden gefundene und behobene Sicherheitslücken häufig besser kommuniziert, da alle Änderungen am Quellcode ohnehin sichtbar sind.
Das wirkt sich auch auf Reaktionszeiten der Software-Distributoren aus: Entsprechend aktualisierte Softwarepakete stehen in der Regel zeitnah bereit und können sofort installiert werden.

Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:dualstack}), die Routingtabellen der VPN-Clients (\ref{req:routing}) anpassen können und in Bezug auf Protokollierung (\ref{req:logging}) konfigurierbar sein.


\section{Suche nach VPN-Serversoftware} \label{sct:software_candidates}
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit aktuellem Debian eingesetzt werden können.
Deshalb sind die Debian-Paketquellen die erste Anlaufstelle für die Suche.
Durch die Nutzung der Paketquellen ist das Installieren von Sicherheitsaktualisierungen über den Debian-Paketmanager möglich.
Arbeitsschritte wie das Anpassen und Kompilieren des Quellcodes, sowie Tests und das Paketieren der Software werden von den Verwaltern der Debian-Pakete ausgeführt.
Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft\cite[][Kapitel 6.5]{book:debian}.

Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden\cite[][Kapitel 6.7 und 6.8]{book:debian}.
Somit muss der Systemadministrator lediglich Upgrades zur nächsthöheren Debian-Version durchführen, da dabei Anpassungen an der Systemkonfiguration notwendig werden.

Im Folgenden werden mögliche Software-Kandidaten aus den Debian-Paketquellen vorgestellt.


\subsection{Strongswan} \label{ssct:strongswan}
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine quelloffene, modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig ist.
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebssystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten.
Strongswan wird unter der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.

IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll.
Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen\cite[Vergleich][Kapitel 2.1]{RFC4301}.
Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll.
Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.

Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
Vor dem Versand wird über den Inhalt und einige Felder des IP-Pakets eine Prüfsumme gebildet.
Die Gegenstelle kann nun die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen\cite[Siehe][Kapitel 3.3.3]{RFC4302}.
Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben\cite[definiert in][]{RFC8221} gewählt werden.
Je nach gewählter Funktion fließen gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket wirklich authentisieren kann.
Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen.

Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen\cite[Siehe][Kapitel 2.8]{RFC4303}.
Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind in \cite[][]{RFC8221} aufgeführt.

IPsec definiert zwei Betriebsvarianten: Den Transportmodus und den Tunnelmodus.
Im Transportmodus werden die Inhalte von IP-Paketen in AH- beziehungsweise ESP-Pakete gekapselt.
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden.

Im Tunnelmodus werden die IP-Paketen selbst in AH- beziehungsweise ESP-Pakete gekapselt.
Im Anschluss werden die AH- beziehungsweise ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
Somit ist der Tunnelmodus im Prinzip für die Umsetzung eines VPN geeignet.

Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite[][]{RFC7296}} und kann darüber authentisiert und verschlüsselt mit Gegenstellen kommunizieren.
Dabei werden mit der Gegenstelle Schlüssel- und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer Strongswan IPsec-Verbindungen im Kernel des Host-Betriebssystems konfigurieren kann.
Die Verarbeitung des durch IPsec geschützten Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
Für lokal ausgeführte Programme ist der Einsatz von IPsec transparent.


\subsection{OpenVPN} \label{ssct:openvpn}
OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur\cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
Sie ist unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig und wird unter der GPLv2-Lizenz verbreitet.
OpenVPN läuft vollständig im Benutzerkontext und unterstützt nach dem Programmstart den Wechsel in einen nicht-privilegierten Benutzerkontext\cite[Siehe][\texttt{--user}]{man:openvpn}.
Für die Bereitstellung einer virtuellen Netzwerkkarte als Schnittstelle zum VPN wird ein TUN/TAP-Treiber verwendet.
Kryptografische Operationen werden nur in OpenVPN durchgeführt, welches diese zu großen Teilen an die quelloffene Bibliothek openssl auslagert\cite[][Abschnitt \enquote{Introduction}]{man:openvpn}.

OpenVPN ist unterstützt IPv4 und IPv6 sowohl innerhalb eines VPN als auch zur Kommunikation zwischen OpenVPN-Dienstprogrammen.



\section{Auswahl einer VPN-Software}
Vorzüge von OpenVPN und IPsec im Vergleich.
Begründung der Auswahl.

Idee: Hier kommen Kategorien hinein: Lizenz, Komplett quelloffen/Abhängigkeiten?, Funktionsumfang, Firewallregeln, Trennung von Steuerdaten und Nutzdaten, Platformabhängigkeit, Komplexität der Konfiguration, Einheitliche Sicherheitsniveaus, Userspace vs Userspace+Kernel, Benutzerfreundlichkeit, Konfiguration bidirektional/unidirektional, Potential für Fehlkonfiguration, Flexibilität

IPsec:
Konfiguration der IPsec-Verbindungen findet im Kernel statt, es ist ein zusätzliches IKEv2-Dienstprogramm notwendig, um die Konfigurationsparameter auszuhandeln und Schlüssel auszutauschen.
Die im Kernel konfigurierten Verbindungen sind immer unidirektional, d.h. für den Schutz von Datenverkehr zwischen zwei Rechnern sind auf beiden Rechnern jeweils zwei konfigurierte Verbindungen notwendig.

Bei gegebenenfalls. entdeckten Sicherheitslücken ergeben sich je nach Betriebssystemkernel unterschiedliche Reaktionszeiten.
Je nach Betriebssystem werden im Kernel gegebenenfalls. nicht alle laut RFC empfohlenen Chiffren gleichermaßen angeboten, dadurch kann ein einheitliches Sicherheitsniveau nur schwer gewährleistet werden.
Strongswan ist zwar grundsätzlich auf allen in \ref{req:clientos} aufgeführten Betriebssystemen lauffähig, jedoch endet die Benutzerfreundlichkeit voraussichtlich dann, wenn man Strongswan unter Windows erst einmal kompilieren muss.
Verlässt man sich auf der Clientseite auf das gegebenenfalls. bereits im Betriebssystem enthaltene IKEv2-Dienstprogramm, so wird die Bedienung über alle Betriebssysteme unterschiedlich sein.
Auch darunter leidet die Benutzerfreundlichkeit.
Durch die insgesamt hohe Komplexität des IPsec-Standards ist eine Fehlersuche im Betrieb nicht unbedingt trivial.
Hinzu kommt, dass durch den hohen Funktionsumfang und die Flexibilität von IPsec Konfigurationen möglich sind, die zwar funktionieren, aber nicht das gewünschte Sicherheitsniveau herstellen.

OpenVPN hat nur einen Kommunikationskanäle (udp/1194), während für IPsec IKEv2 (udp/500 beziehungsweise udp/4500) und die Protokolle AH beziehungsweise ESP freigegeben werden müssen.


Sowohl Strongswan als auch OpenVPN sind vollständig quelloffen.
Da jedoch der Datenverkehr bei IPsec durch den Betriebssystemkernel verarbeitet wird, und dessen Quellcode bei Betriebssystemen von Microsoft oder Apple nicht zur Verfügung steht, scheidet Strongswan als Kandidat aus.


\section{Konzipierung der Benutzerverwaltung}
Anforderungen:
* Soll möglichst "einfach" sein
* Möglichst wenig personenbezogene Daten verarbeiten oder speichern
* Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
* Studenten sollen immer für ein (laufendes?) Semester Zugriff erhalten
* Für Beschäftigte wurde kein Kriterium genannt, allerdings könnten andere Gültigkeitsdauern erwünscht sein.

Möglichkeiten: User+Passwort oder SSL-Zertifikate

Zertifikate:
* klare Laufzeit
* kann nicht erraten werden
* Können schlimmstenfalls via CRL gesperrt werden
* Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
* Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
* Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden

Benutzer/Passwort:
* Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulkonto)
* Einrichtung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
* Benutzerkonten werden automatisch deaktiviert
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential für betroffene Benutzer
* Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche

Gewinner: Zertifikate
Für Zertifikate wird eine Zertifizierungsstelle benötigt.

\section{Konzeption und Umsetzung einer Zertifizierungsstelle}
OpenSSL ist aufgrund der Abhängigkeit von OpenVPN bereits gegeben.
Mit OpenSSL kann man Schlüsselpaare erzeugen, Zertifikatsanträge erzeugen und Zertifikate ausstellen.
Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate mit puren openssl-Befehlen ist nicht einfach.
Da wir Zertifikate auch unbrauchbar machen wollen, muss es möglich sein Zertifikate zu widerrufen.
Eine CRL muss erzeugt werden können, damit diese im OpenVPN-Dienst für die Prüfung der Gültigkeit der Zertifikate verwendet werden kann.

Jetzt kann man viel Zeit investieren, die notwendigen Skripte selbst zu schreiben.
Allerdings hat OpenVPN bereits eine Abhängigkeit auf die Skriptesammlung EasyRSA, welche exakt für diesen Zweck gebaut wurde.
Die von Debian 9 mitgelieferte Version 2.3.x ist schon etwas älter, könnte aber verwendet werden.
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.4(Stand 12.09.2018, siehe github.com/openvpn/easyrsa), die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.

Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github vs irgendwie selbst Skripte schreiben (Wieso das Rad neu erfinden?) - Vorteile/Nachteile
Gegebenenfalls. kurz ein Blick darauf, was alles für Features benötigt werden.
EasyRSAv3 ist eine Neuentwicklung von EasyRSA2.
Die neue Version wird vom OpenVPN-Team weiter entwickelt werden.
Vereinfachte Benutzung der zur Verfügung gestellten Shellskripte
Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots

Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden sollen und diverse Einstellungen durch die Zertifizierungsstelle vorgegeben bzw. vorausgesetzt werden, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA3 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.

Danach: Wie funktioniert die CA mit EasyRSA?
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation

Frage: Welche Einstellungen sind anzupassen?

RSA vs EC? (Geht das mit allen OpenVPN-Clients?)
* Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt.
* Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken.
* RSA ist lange erprobt, Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung)
* Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus).
Empfehlungen des BSI\cite{bsi:tr-02102-1}
\cite{bsi:tr-02102-3}

From man:openvpn:
--tls-cert-profile profile
 OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.

Wie groß soll der Schlüssel sein? [Welche Kurve?]

Zertifikate nur mit CN oder volles Schema?
* Eigentlich egal, keine Vorteile oder Nachteile. Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas.


Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen? 
-> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten
* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.

Laufzeit für Serverzertifikate?
* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre?

Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
* Studenten: 6 Monate (immer bis zum Ende des Semesters).
* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre?

Laufzeit der CA - sinnvolle Werte?
10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.

Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so)


\section{Einrichtung des VPN-Servers}

\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
* IP-Adressen und Routing geklärt
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert
* virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
* Voraussichtlich separate Maschine zur Verwaltung der CA
* Koordination Firewallregeln
** Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
** lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
* Koordination Routing
** IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet -> manuelles Failover möglich
** IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
* Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)


\section{Erstellung eines Betriebskonzept}
Installation/Installationsanleitung
Konfiguration
Inbetriebnahme
notwendige (regelmäßige) Wartungsarbeiten


\chapter{Fazit}
Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?
Gibt es vielleicht Szenarien, in denen sich IPsec doch lohnt?
Ja - eventuell. Sehr große Enterprise-Umgebungen, in denen die personellen Ressourcen für die korrekte Konfiguration vorhanden sind.
Da kann man in homogenen Umgebungen sinnvolle IPsec-Konfigurationen auf hunderten oder tausenden Geräte einrichten.

Der Einsatz von IPsec ist für die Umsetzung eines VPN in das Netzwerk einer Fakultätsabteilung ein Schuss mit einer Kanone auf Spatzen.
In großen Umgebungen eines Konzerns kann die Situation schon etwas anders aussehen: Sofern die IT-Landschaft in einem Konzern homogen aufgestellt ist, könnten auf IPsec spezialisierte Administratoren über Konfigurationsmanagement wie zum Beispiel das Active Directory von Microsoft eine Steigerung der Netzwerksicherheit erzielen oder Außendienstmitarbeitern einen nahtlosen Anschluss an das Firmennetzwerk bieten.


\section{Ausblick}
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von ca. 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
Auch OpenVPN in Version 3 ist schon in der Beta - das könnte man auch im Auge behalten.