From 172b5045b3a749ff97d958d97fabf3da761e0df1 Mon Sep 17 00:00:00 2001 From: wieerwill Date: Tue, 29 Mar 2022 19:01:08 +0200 Subject: [PATCH] IPsec --- Network Security - Cheatsheet.pdf | 4 +- Network Security - Cheatsheet.tex | 819 +++++++++++++----------------- 2 files changed, 368 insertions(+), 455 deletions(-) diff --git a/Network Security - Cheatsheet.pdf b/Network Security - Cheatsheet.pdf index 4c1c30a..93eceb7 100644 --- a/Network Security - Cheatsheet.pdf +++ b/Network Security - Cheatsheet.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:e4a021c643a1e8205b695ff295f6531e406bc77e515f54234d14f0ce161a7ef8 -size 1350684 +oid sha256:3d18f34c444877951fd86a3999cbf36b7361bd10b56937b5853a8009836e0c7e +size 1383563 diff --git a/Network Security - Cheatsheet.tex b/Network Security - Cheatsheet.tex index e8272b8..13f1980 100644 --- a/Network Security - Cheatsheet.tex +++ b/Network Security - Cheatsheet.tex @@ -3212,8 +3212,8 @@ \item PPP wurde ursprünglich für den Betrieb zwischen ,,direkt'' verbundenen Einheiten entwickelt, d.h. Einheiten, die eine gemeinsame Schicht-2-Verbindung haben %\item Beispiel: ein PC und ein Einwahlrouter eines Internetanbieters, die über das Telefonnetz mittels Modem verbunden sind \item Die Grundidee von PPTP besteht darin, die Reichweite des Protokolls auf das gesamte Internet auszudehnen, indem der Transport von PPP-PDUs in IP-Paketen definiert wird - \item Die Nutzlast von PPTP-PDUs sind PPP-Pakete %(ohne schicht-2-spezifische Felder wie HDLC-Flags, Bit-Einfügungen, Steuerzeichen, CRC-Fehlerprüfwerte usw.) - \item PPP-Pakete werden in GRE-Pakete eingekapselt, die wiederum in IP-Pakete eingekapselt werden + \item Die Nutzlast von PPTP-PDUs sind PPP-Pakete %(ohne schicht-2-spezifische Felder wie HDLC-Flags, Bit-Einfügungen, Steuerzeichen, CRC-Fehlerprüfwerte usw.) + \item PPP-Pakete werden in GRE-Pakete eingekapselt, die wiederum in IP-Pakete eingekapselt werden \end{itemize*} %\begin{longtable}[]{@{}l@{}} @@ -3263,16 +3263,16 @@ \item Microsoft Point to Point Encryption Protocol \end{itemize*} \item Allerdings wurde eine Reihe von Schwachstellen in PPTP Version 1 und auch in einer verbesserten Version 2 entdeckt - \item Ein allgemeiner Konsens, PPTP als Standardprotokoll zu übernehmen, konnte in den in den IETF-Arbeitsgruppen nicht erreicht werden - \itemähnliches Protokoll (Layer 2 Forwarding, L2F) von Cisco als konkurrierender Ansatz vorgeschlagen - \item Infolgedessen wurde ein Kompromiss gefunden, der die Vorteile beider Vorschläge in einem einzigen Protokoll zusammenfasst: Layer 2 Tunneling Protocol (L2TP) - \end{itemize*} + \item Ein allgemeiner Konsens, PPTP als Standardprotokoll zu übernehmen, konnte in den in den IETF-Arbeitsgruppen nicht erreicht werden + \itemähnliches Protokoll (Layer 2 Forwarding, L2F) von Cisco als konkurrierender Ansatz vorgeschlagen + \item Infolgedessen wurde ein Kompromiss gefunden, der die Vorteile beider Vorschläge in einem einzigen Protokoll zusammenfasst: Layer 2 Tunneling Protocol (L2TP) + \end{itemize*} \subsubsection{Vergleich von PPTP und L2TP} \begin{itemize*} - \item verwenden PPP, um eine anfängliche Umhüllung für Benutzerpakete bereitzustellen - \item erweitern das PPP-Modell, indem sie erlauben, dass die Layer-2- und PPP-Endpunkte sich auf verschiedenen Geräten befinden - \item unterstützen freiwilliges und obligatorisches Tunneling + \item verwenden PPP, um eine anfängliche Umhüllung für Benutzerpakete bereitzustellen + \item erweitern das PPP-Modell, indem sie erlauben, dass die Layer-2- und PPP-Endpunkte sich auf verschiedenen Geräten befinden + \item unterstützen freiwilliges und obligatorisches Tunneling \item Zugrundeliegendes Netzwerk \begin{itemize*} \item PPTP benötigt IP-Netzwerk für Transport seiner PDUs @@ -3280,18 +3280,18 @@ \end{itemize*} \item PPTP kann nur einen einzigen Tunnel zwischen Endpunkten unterstützen, L2TP ermöglicht die Verwendung mehrerer Tunnel zwischen Endpunkten \item Beide Protokolle bieten eine Header-Kompression: Mit Header-Kompression kommt L2TP mit 4 Byte Overhead aus, im Vergleich zu 6 Byte bei PPTP - \item L2TP ermöglicht z.B. die Erstellung verschiedener Tunnel für unterschiedliche Dienstqualitäten + \item L2TP ermöglicht z.B. die Erstellung verschiedener Tunnel für unterschiedliche Dienstqualitäten \item L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht tut \end{itemize*} \subsection{Virtuelle private Netzwerke} \begin{itemize*} - \item Verschiedene Definitionen - \item privates Netz, das innerhalb einer öffentlichen Netzinfrastruktur, wie dem globalen Internet, aufgebaut ist - \item Kommunikationsumgebung, in der der Zugang kontrolliert wird, um Peer-Verbindungen nur innerhalb einer definierten Interessengemeinschaft zuzulassen%, und die durch eine Form der Partitionierung eines gemeinsamen zugrundeliegenden Kommunikationsmediums aufgebaut ist, wobei dieses zugrundeliegende Kommunikationsmedium dem Netz Dienste auf nicht-exklusiver Basis bereitstellt - \item logisches Computernetzwerk mit eingeschränkter Nutzung, das aus den Systemressourcen eines relativ öffentlichen, physischen Netzwerks aufgebaut ist%, oft unter Verwendung von Verschlüsselung und oft durch Tunneln von Verbindungen des virtuellen Netzwerks über das reale Netzwerk - %\item Anmerkung: Die beiden letzteren Definitionen beinhalten explizit Sicherheitseigenschaften (kontrollierter Zugriff, Verschlüsselung), die erste hingegen nicht - \end{itemize*} + \item Verschiedene Definitionen + \item privates Netz, das innerhalb einer öffentlichen Netzinfrastruktur, wie dem globalen Internet, aufgebaut ist + \item Kommunikationsumgebung, in der der Zugang kontrolliert wird, um Peer-Verbindungen nur innerhalb einer definierten Interessengemeinschaft zuzulassen%, und die durch eine Form der Partitionierung eines gemeinsamen zugrundeliegenden Kommunikationsmediums aufgebaut ist, wobei dieses zugrundeliegende Kommunikationsmedium dem Netz Dienste auf nicht-exklusiver Basis bereitstellt + \item logisches Computernetzwerk mit eingeschränkter Nutzung, das aus den Systemressourcen eines relativ öffentlichen, physischen Netzwerks aufgebaut ist%, oft unter Verwendung von Verschlüsselung und oft durch Tunneln von Verbindungen des virtuellen Netzwerks über das reale Netzwerk + %\item Anmerkung: Die beiden letzteren Definitionen beinhalten explizit Sicherheitseigenschaften (kontrollierter Zugriff, Verschlüsselung), die erste hingegen nicht + \end{itemize*} Techniken zum Aufbau virtueller privater Netze \begin{itemize*} @@ -3319,8 +3319,6 @@ \section{Die IPsec-Architektur für das Internet-Protokoll} \subsection{Überblick} \begin{itemize*} - \item Kurze Einführung in das Internet-Protokoll (IP) - \item Sicherheitsprobleme von IP und Ziele von IPsec \item Die IPsec-Architektur \begin{itemize*} \item Modi des IPsec-Sicherheitsprotokolls Transport/Tunnel-Modus @@ -3333,121 +3331,99 @@ \item Authentifizierungs-Header (AH) \item Encapsulating Security Payload (ESP) \end{itemize*} - \item Entitätsauthentifizierung und der Internet-Schlüsselaustausch (IKE) + \item Entitätsauthentifizierung und Internet-Schlüsselaustausch (IKE) \end{itemize*} \subsection{Die TCP/IP-Protokollsuite} - \begin{itemize*} - \item IP (Internet Protocol): unzuverlässiges, verbindungsloses Netzwerkprotokoll - \item TCP (Transmission Control Protocol): zuverlässiges, verbindungsorientiertes Transportprotokoll, realisiert über IP - \item UDP (User Datagram Protocol): unzuverlässiges, verbindungsloses Transportprotokoll, bietet eine Anwendungsschnittstelle zu IP - \item Beispiele für Anwendungsprotokolle - \begin{itemize*} - \item HTTP: Hypertext-Übertragungsprotokoll - \item SMTP: Einfaches Mail-Übertragungsprotokoll - \end{itemize*} + \begin{description*} + \item[IP] (Internet Protocol) unzuverlässiges, verbindungsloses Netzwerkprotokoll + \item[TCP] (Transmission Control Protocol) zuverlässiges, verbindungsorientiertes Transportprotokoll, realisiert über IP + \item[UDP] (User Datagram Protocol) unzuverlässiges, verbindungsloses Transportprotokoll, bietet eine Anwendungsschnittstelle zu IP + \item Beispiel: HTTP, SMTP %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-tcp-ip-suite.png} - \end{itemize*} + \end{description*} \subsection{Das IPv4-Paketformat} + \begin{center} + \includegraphics[width=.5\linewidth]{Assets/NetworkSecurity-ipv4-packet-format.png} + \end{center} \begin{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipv4-packet-format.png} \item Version (Ver.): 4 bit - \begin{itemize*} - \item Derzeit ist Version 4 weit verbreitet - \item Version 6 ist bereits spezifiziert, aber es ist noch nicht klar, ob sie jemals zum Einsatz kommen wird - \end{itemize*} + %\begin{itemize*} + % \item Derzeit ist Version 4 weit verbreitet + % \item Version 6 ist bereits spezifiziert, aber es ist noch nicht klar, ob sie jemals zum Einsatz kommen wird + %\end{itemize*} \item IP-Header-Länge (IHL): 4 Bit - \begin{itemize*} - \item Länge des IP-Headers in 32-Bit-Wörtern - \end{itemize*} + %\begin{itemize*} + % \item Länge des IP-Headers in 32-Bit-Wörtern + %\end{itemize*} \item Art des Dienstes (TOS): 8 Bit - \begin{itemize*} - \item Dieses Feld könnte verwendet werden, um die Verkehrsanforderungen eines Pakets anzugeben. - \item Jetzt: DCSP und Explicit Congestion (EC) Indication - \end{itemize*} - \item Länge: 16 Bit - \begin{itemize*} - \item Die Länge des Pakets einschließlich des Headers in Oktetten - \item Dieses Feld ist, wie alle anderen Felder in der IP-Suite, in ,,big endian'' Darstellung - \end{itemize*} - \item Kennung: 16 Bit - \begin{itemize*} - \item Dient der ,,eindeutigen'' Identifizierung eines IP-Datagramms - \item Wichtig für das Wiederzusammensetzen von fragmentierten IP-Datagrammen - \end{itemize*} - \item Flaggen: 3 Bit - \begin{itemize*} - \item Bit 1: nicht fragmentieren - \item Bit 2: Datagramm fragmentiert - \item Bit 3: reserviert für zukünftige Verwendung - \end{itemize*} + %\begin{itemize*} + % \item Dieses Feld könnte verwendet werden, um die Verkehrsanforderungen eines Pakets anzugeben. + % \item Jetzt: DCSP und Explicit Congestion (EC) Indication + %\end{itemize*} + \item Länge: 16 Bit, Länge des Pakets einschließlich des Headers + %\begin{itemize*} + % \item Dieses Feld ist, wie alle anderen Felder in der IP-Suite, in ,,big endian'' Darstellung + %\end{itemize*} + \item Kennung: 16 Bit der ,,eindeutigen'' Identifizierung + %\begin{itemize*} + % \item Wichtig für das Wiederzusammensetzen von fragmentierten IP-Datagrammen + %\end{itemize*} + \item Flaggen: 3 Bit (fragmentiert?) + %\begin{itemize*} + % \item Bit 1: nicht fragmentieren + % \item Bit 2: Datagramm fragmentiert + % \item Bit 3: reserviert für zukünftige Verwendung + %\end{itemize*} \item Fragmentierungs-Offset: 13 Bit - \begin{itemize*} - \item Die Position dieses Pakets im entsprechenden IP-Datagramm - \end{itemize*} + %\begin{itemize*} + % \item Die Position dieses Pakets im entsprechenden IP-Datagramm + %\end{itemize*} \item Lebenszeit (TTL): 8 Bit - \begin{itemize*} - \item An jedem verarbeitenden Netzknoten wird dieses Feld um eins dekrementiert - \item Wenn die TTL 0 erreicht, wird das Paket verworfen, um Paketschleifen zu vermeiden. - \end{itemize*} - \item Protokoll: 8 Bit - \begin{itemize*} - \item Gibt das (Transport-)Protokoll der Nutzlast an - \item Wird vom empfangenden Endsystem verwendet, um Pakete zwischen verschiedenen Transportprotokollen wie TCP, UDP, ... zu entmultiplexen. - \end{itemize*} - \item Prüfsumme: 16 Bit - \begin{itemize*} - \item Schutz vor Übertragungsfehlern - \item Da es sich nicht um eine kryptografische Prüfsumme handelt, kann sie leicht gefälscht werden. - \end{itemize*} - \item Quelladresse: 32 Bit - \begin{itemize*} - \item Die IP-Adresse des Absenders dieses Pakets - \end{itemize*} - \item Zieladresse: 32 Bit - \begin{itemize*} - \item Die IP-Adresse des vorgesehenen Empfängers dieses Pakets - \end{itemize*} + %\begin{itemize*} + % \item An jedem verarbeitenden Netzknoten wird dieses Feld um eins dekrementiert + % \item Wenn die TTL 0 erreicht, wird das Paket verworfen, um Paketschleifen zu vermeiden. + %\end{itemize*} + \item Protokoll: 8 Bit, (Transport-)Protokoll der Nutzlast an + %\begin{itemize*} + % \item Wird vom empfangenden Endsystem verwendet, um Pakete zwischen verschiedenen Transportprotokollen wie TCP, UDP, ... zu entmultiplexen. + %\end{itemize*} + \item Prüfsumme: 16 Bit, Schutz vor Übertragungsfehlern + %\begin{itemize*} + % \item Da es sich nicht um eine kryptografische Prüfsumme handelt, kann sie leicht gefälscht werden. + %\end{itemize*} + \item Quelladresse: 32 Bit, IP-Adresse des Absenders + \item Zieladresse: 32 Bit, IP-Adresse des Empfängers \item IP-Optionen: variable Länge - \begin{itemize*} - \item Ein IP-Header kann optional zusätzliche Informationen enthalten. - \item Da sie nicht Bestandteil von IPsec sind, werden sie in diesem Kurs nicht behandelt. - \end{itemize*} + %\begin{itemize*} + % \item Ein IP-Header kann optional zusätzliche Informationen enthalten. + % \item Da sie nicht Bestandteil von IPsec sind, werden sie in diesem Kurs nicht behandelt. + %\end{itemize*} \end{itemize*} \subsection{Sicherheitsprobleme des Internet-Protokolls} \begin{itemize*} - \item Wenn eine Einheit ein IP-Paket empfängt, hat sie keine Garantie für + \item bei Empfang eines IP-Paket, gibt es keine Garantie für \item Authentifizierung der Datenherkunft / Datenintegrität - \begin{itemize*} - \item Das Paket wurde tatsächlich von der Einrichtung gesendet, auf die die Quelladresse des Pakets verweist. - \item Das Paket enthält den ursprünglichen Inhalt des Absenders, so dass es während des Transports nicht verändert worden ist. - \item Die empfangende Einrichtung ist tatsächlich die Einrichtung, an die der Absender das Paket senden wollte. - \end{itemize*} - \item Vertraulichkeit: - \begin{itemize*} - \item Die ursprünglichen Daten wurden auf dem Weg vom Absender zum Empfänger nicht von Dritten eingesehen. - \end{itemize*} + \item Vertraulichkeit: Die ursprünglichen Daten wurden auf dem Weg vom Absender zum Empfänger nicht von Dritten eingesehen. \end{itemize*} \subsection{Sicherheitsziele von IPsec} \begin{itemize*} - \item IPsec zielt darauf ab, die folgenden Sicherheitsziele zu gewährleisten: + \item IPsec zielt darauf ab, die folgenden Sicherheitsziele zu gewährleisten + \item Authentifizierung der Datenherkunft/Datenintegrität \begin{itemize*} - \item Authentifizierung der Datenherkunft / Verbindungslose Datenintegrität: - \begin{itemize*} - \item Es ist nicht möglich, ein IP-Datagramm mit einer maskierten IP-Quell- oder Zieladresse zu senden, ohne dass der Empfänger dies erkennen kann. - \item Es ist nicht möglich, ein IP-Datagramm während der Übertragung zu verändern, ohne dass der Empfänger diese Veränderung feststellen kann. - \item Wiedergabeschutz: Es ist nicht möglich, ein aufgezeichnetes IP-Paket zu einem späteren Zeitpunkt erneut abzuspielen, ohne dass der Empfänger dies erkennen kann. - \end{itemize*} - \item Vertraulichkeit: - \begin{itemize*} - \item Es ist nicht möglich, den Inhalt von IP-Datagrammen zu belauschen - \item Begrenzte Vertraulichkeit des Verkehrsflusses - \end{itemize*} + \item Es ist nicht möglich, ein IP-Datagramm mit einer maskierten IP-Quell- oder Zieladresse zu senden, ohne dass der Empfänger dies erkennen kann + \item Es ist nicht möglich, ein IP-Datagramm während der Übertragung zu verändern, ohne dass der Empfänger diese Veränderung feststellen kann + \item Wiedergabeschutz: Es ist nicht möglich, ein aufgezeichnetes IP-Paket zu einem späteren Zeitpunkt erneut abzuspielen, ohne dass der Empfänger dies erkennen kann \end{itemize*} - \item Sicherheitspolitik: + \item Vertraulichkeit + \begin{itemize*} + \item Es ist nicht möglich, den Inhalt von IP-Datagrammen zu belauschen + \item Begrenzte Vertraulichkeit des Verkehrsflusses + \end{itemize*} + \item Sicherheitspolitik \begin{itemize*} \item Sender, Empfänger und Zwischenknoten können den erforderlichen Schutz für ein IP-Paket gemäß einer lokalen Sicherheitsrichtlinie festlegen \item Zwischenknoten und der Empfänger verwerfen IP-Pakete, die diese Anforderungen nicht erfüllen @@ -3455,128 +3431,111 @@ \end{itemize*} \subsection{Überblick über die IPsec-Standardisierung} - \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IPsec-standardization.png} - - \subsection{Überblick über die IPsec-Architektur} + \begin{center} + \includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-IPsec-standardization.png} + \end{center} \begin{itemize*} + \item RFC 4301 definiert die grundlegende Architektur von IPsec + \item Konzepte: + \begin{itemize*} + \item Sicherheitsvereinigung (SA), Sicherheitsvereinigungsdatenbank (SADB) + \item Sicherheitsrichtlinien, -Datenbank (SPD) + \end{itemize*} + \item Grundlegende IPsec-Protokolle + \begin{itemize*} + \item Authentifizierungs-Header (AH) + \item Encapsulating Security Payload (ESP) + \end{itemize*} + \item Protokoll-Modi: Transport-/Tunnel-Modus + \item Schlüsselmanagement-Verfahren: IKE \& IKEv \item RFC 4301 definiert die grundlegende Architektur von IPsec: \begin{itemize*} - \item Konzepte: - \begin{itemize*} - \item Sicherheitsvereinigung (SA), Sicherheitsvereinigungsdatenbank (SADB) - \item Sicherheitsrichtlinien, Sicherheitsrichtlinien-Datenbank (SPD) - \end{itemize*} - \item Grundlegende IPsec-Protokolle: - \begin{itemize*} - \item Authentifizierungs-Header (AH) - \item Encapsulating Security Payload (ESP) - \end{itemize*} - \item Protokoll-Modi: - \begin{itemize*} - \item Transport-Modus - \item Tunnel-Modus - \end{itemize*} - \item Schlüsselmanagement-Verfahren: - \begin{itemize*} - \item IKE \& IKEv - \end{itemize*} + \item Verwendung von verschiedenen kryptographischen Primitiven mit AH und ESP + \item Verschlüsselung: 3DES-CBC, AES und andere CBC + \item Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, AES-GMAC + \item Authentifizierte Verschlüsselung: GCM und ,,Zähler mit CBC-MAC,, (CCM), beide für AES definiert \end{itemize*} - \item RFC 4301 definiert die grundlegende Architektur von IPsec: + \item Eine Sicherheitsassoziation (SA) ist eine Simplex-Verbindung, die Sicherheitsdienste für den von ihr beförderten Verkehr bereitstellt \begin{itemize*} - \item Verwendung von verschiedenen kryptographischen Primitiven mit AH und ESP: - \begin{itemize*} - \item Verschlüsselung: 3DES-CBC, AES und andere CBC-Verschlüsselungsalgorithmen, AES-Zählermodus - \item Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, HMAC- RIPEMD-160, AES-GMAC, AES-CMAC, AES-XCBC... - \item Authentifizierte Verschlüsselung: GCM und ,,Zähler mit CBC-MAC,, (CCM), beide für AES definiert - \end{itemize*} - \end{itemize*} - \item Eine Sicherheitsassoziation (SA) ist eine Simplex- ,,Verbindung'', die Sicherheitsdienste für den von ihr beförderten Verkehr bereitstellt. - \begin{itemize*} - \item Sicherheitsdienste werden für eine SA entweder mit AH oder ESP bereitgestellt, jedoch nicht mit beiden. - \item Für bidirektionale Kommunikation sind zwei Sicherheitsverbindungen erforderlich. - \item Eine SA wird eindeutig durch ein Tripel identifiziert, das aus einem Sicherheitsparameterindex (SPI), einer IP-Zieladresse und einer Sicherheitsprotokollkennung (AH / ESP) besteht. - \item Eine SA kann zwischen den folgenden Gegenstellen eingerichtet werden: + \item Sicherheitsdienste werden für eine SA entweder mit AH oder ESP bereitgestellt, jedoch nicht mit beiden + \item Für bidirektionale Kommunikation sind zwei Sicherheitsverbindungen erforderlich + \item Eine SA wird eindeutig durch ein Tripel identifiziert, das aus einem Sicherheitsparameterindex (SPI), einer IP-Zieladresse und einer Sicherheitsprotokollkennung (AH/ESP) besteht + \item Eine SA kann zwischen den folgenden Gegenstellen eingerichtet werden \begin{itemize*} \item Host $\leftrightarrow$ Host \item Host $\leftrightarrow$ Gateway (oder andersherum) \item Gateway $\leftrightarrow$ Gateway \end{itemize*} - \item Es gibt zwei konzeptionelle Datenbanken, die mit SAs verbunden sind: + \item zwei konzeptionelle Datenbanken, die mit SAs verbunden \begin{itemize*} - \item Die Sicherheitsrichtliniendatenbank (SPD) legt fest, welche Sicherheitsdienste für welche IP-Pakete auf welche Weise bereitgestellt werden sollen. - \item Die Sicherheitsassoziationsdatenbank (SADB) + \item Sicherheitsrichtliniendatenbank (SPD) legt fest, welche Sicherheitsdienste für welche IP-Pakete auf welche Weise bereitgestellt werden sollen. + \item Sicherheitsassoziationsdatenbank (SADB) \end{itemize*} \end{itemize*} - \item Protokollmodi - Eine SA ist immer von einem der folgenden Typen: + \item Protokollmodi - Eine SA ist immer von einem der folgenden Typen \begin{itemize*} - \item Der Transportmodus kann nur zwischen den Endpunkten einer Kommunikation verwendet werden: - \begin{itemize*} - \item host $\leftrightarrow$ host, oder - \item Host $\leftrightarrow$-Gateway, wenn das Gateway ein Kommunikationsendpunkt ist (z.B. für die Netzverwaltung) - \end{itemize*} - \item Der Tunnelmodus kann für beliebige Peers verwendet werden. + \item Der Transportmodus kann nur zwischen den Endpunkten einer Kommunikation verwendet werden + \item Der Tunnelmodus kann für beliebige Peers verwendet werden \end{itemize*} \end{itemize*} - Der Unterschied zwischen den beiden Modi ist, dass: - - Im Transportmodus wird lediglich ein sicherheitsspezifischer Header (+ eventueller Trailer) hinzugefügt - \begin{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-transport-mode.png} \end{itemize*} - \item Der Tunnelmodus kapselt IP-Pakete ein: Die Verkapselung von IP-Paketen ermöglicht es einem Gateway, den Verkehr im Namen anderer Entitäten zu schützen (z.B. Hosts eines Subnetzes usw.) - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-tunnel-mode.png} \end{itemize*} - \item Der Authentifizierungs-Header (AH): + Der Unterschied zwischen den beiden Modi ist, dass + \begin{description*} + \item[Transportmodus] sicherheitsspezifischer Header (+ eventueller Trailer) hinzugefügt + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-transport-mode.png} + \item[Tunnelmodus] kapselt IP-Pakete ein: Die Verkapselung von IP-Paketen ermöglicht es einem Gateway, den Verkehr im Namen anderer Entitäten zu schützen + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-tunnel-mode.png} + \item [Authentifizierungs-Header] (AH) \begin{itemize*} \item Bietet Authentifizierung der Datenherkunft und Schutz vor Wiederholung \item Wird als Header realisiert, der zwischen dem IP-Header und den zu schützenden Daten eingefügt wird % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-AH.png} \end{itemize*} - \item Die einkapselnde Sicherheitsnutzlast (ESP): + \item[einkapselnde Sicherheitsnutzlast] (ESP) \begin{itemize*} \item Bietet Authentifizierung der Datenherkunft, Vertraulichkeit und Schutz vor Wiederholung \item Wird mit einem Header und einem Trailer realisiert, der die zu schützenden Daten einkapselt % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-ESP.png} \end{itemize*} - \item Die Einrichtung von Sicherheitsvereinigungen wird mit: + \end{description*} + + Einrichtung von Sicherheitsvereinigungen mit + \begin{itemize*} + \item Internet Security Association Key Management Protocol (ISAKMP) \begin{itemize*} - \item Internet Security Association Key Management Protocol (ISAKMP): - \begin{itemize*} - \item Definiert einen generischen Rahmen für die Schlüsselauthentifizierung, den Schlüsselaustausch und die Aushandlung von Sicherheitsassoziationsparametern - \item Definiert kein spezifisches Authentifizierungsprotokoll, aber spezifiziert: Paketformate, Zeitgeber für die Weiterleitung, Anforderungen an den Nachrichtenaufbau - \end{itemize*} - \item Internet-Schlüsselaustausch (IKE): - \begin{itemize*} - \item Definiert ein Authentifizierungs- und Schlüsselaustauschprotokoll - \item Ist konform zu ISAKMP und kann für verschiedene Anwendungen verwendet werden - \item Der Aufbau von IPsec SAs zwischen zwei Entitäten wird in zwei Phasen realisiert: - \item Einrichtung einer IKE SA (definiert, wie man IPsec SAs einrichtet) - \item Einrichtung von IPsec SAs - \end{itemize*} + \item Definiert einen generischen Rahmen für die Schlüsselauthentifizierung, den Schlüsselaustausch und die Aushandlung von Sicherheitsassoziationsparametern + \item Definiert kein spezifisches Authentifizierungsprotokoll, aber spezifiziert: Paketformate, Zeitgeber für die Weiterleitung, Anforderungen an den Nachrichtenaufbau + \end{itemize*} + \item Internet-Schlüsselaustausch (IKE) + \begin{itemize*} + \item Definiert ein Authentifizierungs- und Schlüsselaustauschprotokoll + \item Ist konform zu ISAKMP und kann für verschiedene Anwendungen verwendet werden + \item Der Aufbau von IPsec SAs zwischen zwei Entitäten wird in zwei Phasen realisiert + \item 1. Einrichtung einer IKE SA %(definiert, wie man IPsec SAs einrichtet) + \item 2. Einrichtung von IPsec SAs \end{itemize*} \end{itemize*} \subsection{IPsec-Wiedergabeschutz (Replay protection)} \begin{itemize*} - \item Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine - Sequenznummer, die einen Wiedergabeschutz realisiert: + \item Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine Sequenznummer, die einen Wiedergabeschutz realisiert \begin{itemize*} - \item Beim Einrichten einer SA wird diese Sequenznummer auf Null initialisiert. - \item Die Sequenznummer wird mit jedem gesendeten IP-Paket erhöht - \item Die Sequenznummer ist 32 Bit lang, es wird ein neuer Sitzungsschlüssel benötigt, bevor ein Wrap-around erfolgt + \item Beim Einrichten einer SA wird diese Sequenznummer auf Null initialisiert + \item SeqNr wird mit jedem gesendeten IP-Paket erhöht + \item SeqNr ist 32 Bit lang, es wird ein neuer Sitzungsschlüssel benötigt, bevor ein Wrap-around erfolgt \item Der Empfänger eines IP-Pakets prüft, ob die Sequenznummer in einem Fenster zulässiger Nummern enthalten ist % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection.png} (Paket mit Sequenznummer N kann noch akzeptiert werden) \end{itemize*} \item Wenn ein empfangenes Paket eine Sequenznummer hat, die \begin{itemize*} - \item links vom aktuellen Fenster $\Rightarrow$ liegt, lehnt der Empfänger das Paket ab - \item innerhalb des aktuellen Fensters $\Rightarrow$ liegt, nimmt der Empfänger das Paket an - \item liegt rechts vom aktuellen Fenster $\Rightarrow$ der Empfänger nimmt das Paket an und schiebt das Fenster weiter + \item links vom Fenster $\Rightarrow$ lehnt Empfänger das Paket ab + \item innerhalb des Fensters $\Rightarrow$ nimmt Empfänger das Paket an + \item liegt rechts vom Fenster $\Rightarrow$ Empfänger nimmt das Paket an und schiebt das Fenster weiter \item Natürlich werden IP-Pakete nur akzeptiert, wenn sie die Authentifizierungsprüfung bestehen und das Fenster wird niemals vor dieser Prüfung weitergeschaltet \end{itemize*} - \item Die minimale Fenstergröße beträgt 32 Pakete (64 Pakete werden empfohlen) - %\begin{itemize*} - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection2.png} + \item minimale Fenstergröße beträgt 32 Pakete (64 Pakete empfohlen) + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection2.png} %\item Paket mit Sequenznummer N kann nicht mehr akzeptiert werden - %\end{itemize*} \end{itemize*} \subsection{IPsec-Implementierungsalternativen: Host-Implementierung} @@ -3590,7 +3549,7 @@ \item Zwei Hauptalternativen zur Integration: \end{itemize*} \begin{tabular}{p{4cm}|p{4cm}} - Integriertes Betriebssystem & ,,Bump'' im Stack \\\hline + Integriertes Betriebssystem & ,,Bump'' in Stack \\\hline Anwendung & Anwendung \\ Transport & Transport \\ Netzwerk + IPsec & Netzwerk \\ @@ -3602,63 +3561,54 @@ \subsection{IPsec-Implementierungsalternativen: Router-Implementierung} \begin{itemize*} - \item Vorteile der IPsec-Implementierung in Routern: + \item Vorteile der IPsec-Implementierung in Routern + \item Möglichkeit, IP-Pakete zu sichern, die zwischen zwei Netzen über ein öffentliches Netz wie das Internet fließen \begin{itemize*} - \item Möglichkeit, IP-Pakete zu sichern, die zwischen zwei Netzen über ein öffentliches Netz wie das Internet fließen: - \begin{itemize*} - \item Ermöglicht die Einrichtung virtueller privater Netzwerke (VPNs) - \item Keine Notwendigkeit, IPsec in jedes Endsystem zu integrieren - \end{itemize*} - \item Fähigkeit zur Authentifizierung und Autorisierung des IP-Verkehrs, der von entfernten Benutzern eingeht + \item Ermöglicht die Einrichtung virtueller privater Netzwerke (VPNs) + \item Keine Notwendigkeit, IPsec in jedes Endsystem zu integrieren \end{itemize*} - \item Zwei Hauptalternativen für die Implementierung: - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-router-implementation.png} + \item Fähigkeit zur Authentifizierung und Autorisierung des IP-Verkehrs, der von entfernten Benutzern eingeht + %\item Zwei Hauptalternativen für die Implementierung: + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-router-implementation.png} \end{itemize*} - \subsection{Wann sollte welcher IPsec-Modus verwendet werden?} + \subsection{Wann welchen IPsec-Modus verwenden?} \begin{itemize*} - \item In den meisten Fällen handelt es sich bei den Kommunikationsendpunkten um Hosts (Workstations, Server), aber das ist nicht unbedingt der Fall: - \begin{itemize*} - \item Beispiel: ein Gateway wird über SNMP von einer Workstation verwaltet - \end{itemize*} - \item Der Transportmodus wird verwendet, wenn die ,,kryptografischen Endpunkte'' auch die ,,Kommunikationsendpunkte'' der gesicherten IP-Pakete sind + \item In den meisten Fällen handelt es sich bei den Kommunikationsendpunkten um Hosts, aber das ist nicht unbedingt der Fall + %\item Beispiel: ein Gateway wird über SNMP von einer Workstation verwaltet + \item Der Transportmodus wird verwendet, wenn die kryptografischen Endpunkte auch die Kommunikationsendpunkte der gesicherten IP-Pakete sind \begin{itemize*} \item Kryptografische Endpunkte: die Entitäten, die einen IPsec-Header (AH oder ESP) erzeugen/verarbeiten \item Kommunikationsendpunkte: Quelle und Ziel eines IP-Pakets - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-endpoints.png} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-endpoints.png} \end{itemize*} - \item Der Tunnelmodus wird verwendet, wenn mindestens ein ,,kryptographischer Endpunkt'' nicht ein ,,Kommunikationsendpunkt'' der gesicherten IP-Pakete ist + \item Der Tunnelmodus wird verwendet, wenn mindestens ein kryptographischer Endpunkt nicht ein Kommunikationsendpunkt der gesicherten IP-Pakete ist \begin{itemize*} \item Dies ermöglicht Gateways, die den IP-Verkehr im Namen anderer Stellen sichern % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-tunneling.png} \end{itemize*} - \item Die obige Beschreibung der Anwendungsszenarien für den Tunnelmodus umfasst auch den Fall, dass nur ein kryptografischer Endpunkt kein Kommunikationsendpunkt ist: - \begin{itemize*} - \item Beispiel: ein Sicherheitsgateway, das die Authentifizierung und/oder die Vertraulichkeit des IP-Verkehrs zwischen einem lokalen Teilnetz und einem über das Internet verbundenen Host sicherstellt (,,Road Warrior Szenario'') - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-tunnelung-2.png} - \end{itemize*} + \item Die obige Beschreibung der Anwendungsszenarien für den Tunnelmodus umfasst auch den Fall, dass nur ein kryptografischer Endpunkt kein Kommunikationsendpunkt ist + %\item Beispiel: ein Sicherheitsgateway, das die Authentifizierung und/oder die Vertraulichkeit des IP-Verkehrs zwischen einem lokalen Teilnetz und einem über das Internet verbundenen Host sicherstellt (,,Road Warrior Szenario'') + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-tunnelung-2.png} \end{itemize*} \subsection{Verschachtelung von Sicherheitsassoziationen} \begin{itemize*} - \item Sicherheitsassoziationen können verschachtelt werden: - \begin{itemize*} - \item Beispiel: Host A und Gateway RB führen eine Authentifizierung der Datenherkunft durch und die Gateways RA und RB führen eine Vertraulichkeit von Subnetz zu Subnetz durch - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-nesting.png} - \end{itemize*} + \item Sicherheitsassoziationen können verschachtelt werden + %\item Beispiel: Host A und Gateway RB führen eine Authentifizierung der Datenherkunft durch und die Gateways RA und RB führen eine Vertraulichkeit von Subnetz zu Subnetz durch + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-nesting.png} \item Bei der Verschachtelung von SAs muss jedoch darauf geachtet werden, dass keine ,,falsche Klammerung'' von SAs erfolgt - \begin{itemize*} - \item Ein Beispiel für eine gültige SA-Schachtelung: - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-nesting-2.png} - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-nesting-3.png} - \item Da das Paket von RB nach RD getunnelt wird, kann das Gateway RC den inneren IPsec-Header nicht verarbeiten - \item Ein mögliches Ergebnis dieser fehlerhaften Konfiguration könnte sein, dass das Paket zurück nach RC geroutet wird - \end{itemize*} + \item \includegraphics[width=.7\linewidth]{Assets/NetworkSecurity-communication-nesting-2.png} + %\begin{itemize*} + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-nesting-3.png} + % \item Da das Paket von RB nach RD getunnelt wird, kann das Gateway RC den inneren IPsec-Header nicht verarbeiten + % \item Ein mögliches Ergebnis dieser fehlerhaften Konfiguration könnte sein, dass das Paket zurück nach RC geroutet wird + %\end{itemize*} \end{itemize*} - \subsection{Grundschema der IPsec-Verarbeitung: Ausgehende Pakete} + \subsection{IPsec-Verarbeitung: Ausgehende Pakete} \begin{itemize*} - \item Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) wird angewiesen, ein IP-Paket an einen anderen Knoten (Host/Gateway) zu senden + \item Nehmen wir an, die IP-Schicht eines Knotens wird angewiesen, ein IP-Paket an einen anderen Knoten zu senden \item Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen \item Feststellen, ob und wie das ausgehende Paket gesichert werden muss \begin{itemize*} @@ -3670,48 +3620,40 @@ \begin{itemize*} \item Wenn es noch keine passende SA mit dem entsprechenden Knoten gibt, dann fordere den Key Management Demon auf, einen IKE durchzuführen \end{itemize*} - \item Die ermittelte (und eventuell neu erstellte) SA in der SADB nachschlagen - \item Führen Sie die von der SA festgelegte Sicherheitstransformation durch, indem Sie den Algorithmus, seine Parameter und den Schlüssel, wie in der SA angegeben, verwenden. + \item Die ermittelte SA in der SADB nachschlagen + \item Führe die von der SA festgelegte Sicherheitstransformation durch, unter Verwendung des Algorithmus, seine Parameter und den Schlüssel, wie in der SA angegeben \begin{itemize*} - \item Dies resultiert in der Konstruktion eines AH- oder ESP-Headers - \item Eventuell wird auch ein neuer (äußerer) IP-Header erstellt (Tunnelmodus) + \item resultiert in der Konstruktion eines AH- oder ESP-Headers + \item Eventuell wird auch ein neuer (äußerer) IP-Header erstellt %(Tunnelmodus) \end{itemize*} - \item Senden Sie das resultierende IP-Paket $\Rightarrow$ done + \item Sende das resultierende IP-Paket $\Rightarrow$ done \end{itemize*} - \subsection{Grundschema der IPsec-Verarbeitung: Eingehende Pakete} + \subsection{IPsec-Verarbeitung: Eingehende Pakete} \begin{itemize*} - \item Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) empfängt ein IP-Paket von einem anderen Knoten (Host/Gateway) + \item Nehmen wir an, die IP-Schicht eines Knotens empfängt ein IP-Paket von einem anderen Knoten \item Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen - \item Feststellen, ob das Paket einen IPsec-Header enthält, den diese Einheit verarbeiten soll: + \item Feststellen, ob das Paket einen IPsec-Header enthält, den diese Einheit verarbeiten soll \begin{itemize*} - \item Wenn es einen solchen IPsec-Header gibt, dann suchen Sie die SA in der SADB, die durch den SPI des IPsec-Headers spezifiziert ist, und führen Sie die entsprechende IPsec-Verarbeitung durch - \item Wenn die SA, auf die der SPI verweist, (noch) nicht existiert, verwerfen Sie das Paket + \item Wenn es einen solchen IPsec-Header gibt, dann suche die SA in der SADB, die durch den SPI des IPsec-Headers spezifiziert ist, und führe die entsprechende IPsec-Verarbeitung durch + \item Wenn die SA, auf die der SPI verweist, nicht existiert, verwerfen das Paket \end{itemize*} - \item Ermitteln, ob und wie das Paket hätte geschützt werden sollen: + \item Ermitteln, ob und wie das Paket hätte geschützt werden sollen \begin{itemize*} \item Dies wird wiederum durch einen Lookup im SPD realisiert, wobei der Lookup im Falle von getunnelten Paketen durch Auswertung des inneren IP-Headers durchgeführt wird - \item Wenn die Richtlinie ,,Verwerfen'' vorschreibt, wird das Paket verworfen. - \item Wenn der Schutz des Pakets nicht mit der Richtlinie übereinstimmt, wird das Paket verworfen. - \item Wenn das Paket ordnungsgemäß gesichert wurde, dann übergebe es an die entsprechende Protokollinstanz (Netzwerk-/Transportschicht) + \item Wenn die Richtlinie ,,Verwerfen'' vorschreibt, wird das Paket verworfen + \item Wenn der Schutz des Pakets nicht mit der Richtlinie übereinstimmt, wird das Paket verworfen + \item Wenn das Paket ordnungsgemäß gesichert wurde, dann übergebe es an die entsprechende Protokollinstanz \end{itemize*} \end{itemize*} \subsection{Auswahl der IPsec-Sicherheitspolitik} - Die folgenden Selektoren, die aus den Headern der Netzwerk- und Transportschicht extrahiert werden, ermöglichen die Auswahl einer bestimmten Richtlinie im SPD: + Die folgenden Selektoren, die aus den Headern der Netzwerk- und Transportschicht extrahiert werden, ermöglichen die Auswahl einer bestimmten Richtlinie im SPD \begin{itemize*} - \item IP-Quelladresse: Bestimmter Host, Netzwerkpräfix, Adressbereich oder Platzhalter - \item IP-Zieladresse: - \begin{itemize*} - \item Bestimmter Host, Netzwerk-Präfix, Adressbereich oder Platzhalter - \item Im Falle eingehender getunnelter Pakete wird der innere Header ausgewertet - \end{itemize*} - \item Protokoll: - \begin{itemize*} - \item Der Protokoll-Identifikator des Transportprotokolls für dieses Paket - \item Dies ist möglicherweise nicht zugänglich, wenn ein Paket mit ESP gesichert ist. - \end{itemize*} - \item Ports der oberen Schicht: Falls zugänglich, die Ports der oberen Schicht für die sitzungsorientierte Policy-Auswahl + \item IP-Quelladresse: Bestimmter Host, Netzwerkpräfix, Adressbereich + \item IP-Zieladresse: Bestimmter Host, Netzwerk-Präfix, Adressbereich + \item Protokoll: Protokoll-Identifikator des Transportprotokolls + \item Ports der oberen Schicht: Falls zugänglich %die Ports der oberen Schicht für die sitzungsorientierte Policy-Auswahl \end{itemize*} \subsection{IPsec Security Policy Definition} @@ -3720,30 +3662,30 @@ \item Wie die Einrichtung einer IKE SA zwischen zwei Knoten durchgeführt werden soll \begin{itemize*} \item Identifizierung: DNS-Name oder andere Namenstypen, wie in der IPsec-Domäne der Interpretation eines Protokolls zur Einrichtung von SAs definiert - \item Phase I-Modus: Hauptmodus oder aggressiver Modus (siehe unten) + \item Phase I-Modus: Hauptmodus oder aggressiver Modus \item Schutzsuite(n): Angabe, wie die IKE-Authentifizierung durchgeführt wird \end{itemize*} - \item Welche und wie Sicherheitsdienste für IP-Pakete bereitgestellt werden sollen: + \item Welche und wie Sicherheitsdienste für IP-Pakete bereitgestellt werden sollen \begin{itemize*} \item Selektoren, die bestimmte Flüsse identifizieren - \item Sicherheitsattribute für jeden Fluss: + \item Sicherheitsattribute für jeden Fluss \item Sicherheitsprotokoll: AH oder ESP \item Protokollmodus: Transport- oder Tunnelmodus \item Sicherheitstransformationen: kryptografische Algorithmen und Parameter \item Andere Parameter: SA-Lebensdauer, Replay-Fenster \item Aktion: Verwerfen, Sichern, Umgehen \end{itemize*} - \item Wenn bereits eine SA mit einem entsprechenden Sicherheitsendpunkt eingerichtet ist, wird im SPD auf diese verwiesen. + \item Wenn bereits eine SA mit einem entsprechenden Sicherheitsendpunkt eingerichtet ist, wird im SPD auf diese verwiesen \end{itemize*} - \subsection{Die Encapsulating Security Payload} + \subsection{Encapsulating Security Payload} \begin{itemize*} - \item ESP ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen einen Wiederholungsschutz und einen oder beide der folgenden Sicherheitsdienste bietet: + \item ESP ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen einen Wiederholungsschutz und einen oder beide der folgenden Sicherheitsdienste bietet \begin{itemize*} \item Vertraulichkeit durch Verschlüsselung der eingekapselten Pakete oder nur ihrer Nutzlast \item Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung von MACs zu Paketen \end{itemize*} - \item Die ESP-Definition gliedert sich in zwei Teile: + \item Die ESP-Definition gliedert sich in zwei Teile \begin{itemize*} \item Die Definition des Basisprotokolls \begin{itemize*} @@ -3751,76 +3693,66 @@ \item Verarbeitung des Basisprotokolls \item Tunnel- und Transportmodusbetrieb \end{itemize*} - \item Die Verwendung spezifischer kryptographischer Algorithmen mit ESP: + \item Die Verwendung spezifischer kryptographischer Algorithmen mit ESP \begin{itemize*} - \item Verschlüsselung: 3DES-CBC, AES-CBC, AES-Zählmodus, Verwendung anderer Chiffren im CBC-Modus + \item Verschlüsselung: 3DES-CBC, AES-CBC, CBC-Modi,... \item Authentifizierung: HMAC-MD5-96, HMAC-SHA-96,... \end{itemize*} \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ESP.png} + \item Der ESP-Header folgt unmittelbar auf einen IP-Header oder einen AH-Header + \item Das Next-Header-Feld des vorangehenden Headers zeigt ,,50'' für ESP an + \item Das SPI-Feld gibt die SA an, die für dieses Paket verwendet werden soll + %\begin{itemize*} + % \item Der SPI-Wert wird immer von der empfangenden Seite während der SA-Aushandlung bestimmt, da der Empfänger das Paket verarbeiten muss. + %\end{itemize*} + \item Sequenznummer bietet Schutz vor Wiederholung + \item Wenn der verwendete kryptographische Algorithmus einen Initialisierungsvektor benötigt, wird dieser in jedem Paket am Anfang der Nutzlast im Klartext übertragen + \item Das Pad-Feld dient der Sicherstellung: Auffüllen der Nutzlast bis zur erforderlichen Blocklänge der verwendeten Chiffre + %\item Auffüllen der Nutzlast, um die Felder pad-length und next-header rechtsbündig in die höherwertigen 16 Bit eines 32-Bit-Wortes einzupassen + %\item Die Auffülllänge gibt die Anzahl der hinzugefügten Auffüllbytes an. + \item Das next-header-Feld des ESP-Headers gibt die eingekapselte Nutzlast an \begin{itemize*} - \item Der ESP-Header folgt unmittelbar auf einen IP-Header oder einen AH-Header - \item Das Next-Header-Feld des vorangehenden Headers zeigt ,,50'' für ESP an - \item Das SPI-Feld gibt die SA an, die für dieses Paket verwendet werden soll: - \begin{itemize*} - \item Der SPI-Wert wird immer von der empfangenden Seite während der SA-Aushandlung bestimmt, da der Empfänger das Paket verarbeiten muss. - \end{itemize*} - \item Die Sequenznummer bietet, wie bereits erläutert, Schutz vor Wiederholung. - \item Wenn der verwendete kryptographische Algorithmus einen Initialisierungsvektor benötigt, wird dieser in jedem Paket am Anfang der Nutzlast im Klartext übertragen - \item Das Pad-Feld dient der Sicherstellung: - \begin{itemize*} - \item Auffüllen der Nutzlast bis zur erforderlichen Blocklänge der verwendeten Chiffre - \item Auffüllen der Nutzlast, um die Felder pad-length und next-header rechtsbündig in die höherwertigen 16 Bit eines 32-Bit-Wortes einzupassen - \end{itemize*} - \item Die Auffülllänge gibt die Anzahl der hinzugefügten Auffüllbytes an. - \item Das next-header-Feld des ESP-Headers gibt die eingekapselte Nutzlast an: - \begin{itemize*} - \item Im Falle des Tunnelmodus: IP - \item Im Falle des Transportmodus: ein beliebiges Protokoll der höheren Schicht wie TCP, UDP, ... - \end{itemize*} - \item Das optionale Feld authentication-data enthält eine MAC, falls vorhanden + \item Im Falle des Tunnelmodus: IP + \item Im Falle des Transportmodus: beliebiges Protokoll wie TCP, UDP \end{itemize*} + \item Das optionale Feld authentication-data enthält eine MAC, falls vorhanden %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ESP-processing.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ESP-prepare-header.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ESP-inbound-processing.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ESP-inbound-processing-2.png} - \item Beachten Sie, dass das entkapselte IP-Paket ein fragmentiertes Paket sein kann: + \item Beachte, dass das entkapselte IP-Paket ein fragmentiertes Paket sein kann \begin{itemize*} - \item Dies kann vorkommen, wenn ESP von einem Router im Tunnelmodus angewendet wurde. + \item Dies kann vorkommen, wenn ESP von einem Router im Tunnelmodus angewendet wurde \item Um die Konformität mit der SA-Policy korrekt zu prüfen, müssen alle zu diesem Paket gehörenden Fragmente vom Router empfangen werden, bevor die Prüfung durchgeführt werden kann - \item Beispiel: In einer SA sind nur Pakete an einen bestimmten Port erlaubt + %\item Beispiel: In einer SA sind nur Pakete an einen bestimmten Port erlaubt \item Die erforderliche Port-Information ist nur im ersten Fragment des IP-Pakets vorhanden \end{itemize*} - \item Paketzustellung bedeutet Zustellung an die entsprechende Verarbeitungseinheit: + \item Paketzustellung bedeutet Zustellung an die entsprechende Verarbeitungseinheit \begin{itemize*} \item Wenn ein anderer IPsec-Header für diese Entität vorhanden ist $\Rightarrow$ IPsec-Verarbeitung \item Im Tunnelmodus $\Rightarrow$ Übermittlung des Pakets - \item Im Transportmodus $\Rightarrow$ Aufruf des entsprechenden Protokoll-Headers (TCP, UDP, etc.) + \item Im Transportmodus $\Rightarrow$ Aufruf des entsprechenden Protokoll-Headers %(TCP, UDP, etc.) \end{itemize*} - \item Wenn ESP sowohl Vertraulichkeit als auch Authentifizierung bietet, können für beide Dienste unterschiedliche Schlüssel verwendet werden. - \begin{itemize*} - \item Dies muss während der Einrichtung der ESP-SA ausgehandelt werden. - \end{itemize*} - \item Beachten Sie, dass die Verwendung von ESP ohne Authentifizierung unsicher ist... + \item Wenn ESP sowohl Vertraulichkeit als auch Authentifizierung bietet, können für beide Dienste unterschiedliche Schlüssel verwendet werden. %Dies muss während der Einrichtung der ESP-SA ausgehandelt werden. + \item Verwendung von ESP ohne Authentifizierung unsicher \begin{itemize*} \item Kein zuverlässiger Schutz vor Wiederholungen - \item Zumindest, wenn im CBC-Modus verwendet: - \begin{itemize*} - \item Aktive Angriffe ermöglichen die Wiederherstellung von Nachrichten - \item Beispiel: Bits umdrehen und prüfen, ob Fehlermeldungen erzeugt werden - \item Vollständige Wiederherstellung von Klartextblöcken - \end{itemize*} + \item Zumindest, wenn im CBC-Modus verwendet + \item Aktive Angriffe ermöglichen die Wiederherstellung von Nachrichten + \item Beispiel: Bits umdrehen und prüfen, ob Fehlermeldungen erzeugt werden + \item Vollständige Wiederherstellung von Klartextblöcken \end{itemize*} \end{itemize*} \subsection{Der Authentifizierungs-Header} \begin{itemize*} - \item AH ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen Schutz bietet: + \item AH ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen Schutz bietet \begin{itemize*} \item Wiedergabeschutz - \item Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung von MACs zu den Paketen + \item Authentifizierung der Datenherkunft durch MACs \end{itemize*} - \item Wie bei ESP ist die AH-Definition in zwei Teile aufgeteilt: + \item Wie bei ESP ist die AH-Definition in zwei Teile aufgeteilt \begin{itemize*} \item Die Definition des Basisprotokolls \begin{itemize*} @@ -3828,103 +3760,95 @@ \item Verarbeitung des Basisprotokolls \item Tunnel- und Transportmodusbetrieb \end{itemize*} - \item Die Verwendung spezifischer kryptographischer Algorithmen bei AH: + \item Die Verwendung spezifischer kryptographischer Algorithmen bei AH \begin{itemize*} - \item Authentifizierung: HMAC-MD5-96, HMAC-SHA1-96, HMAC-SHA2, ... - \item Wenn sowohl ESP als auch AH von einer Stelle angewendet werden sollen, wird immer zuerst ESP angewendet: + \item Authentifizierung: HMAC-MD5-96, HMAC-SHA2, ... + \item bei ESP und AH, wird immer zuerst ESP angewendet + \item Dies führt dazu, dass AH der äußere Header ist \end{itemize*} - \item Dies führt dazu, dass AH der äußere Header ist. \item ,,Vorteil'': der IP-Header kann auch durch AH geschützt werden - \item Anmerkung: Für jede Richtung werden zwei SAs (je eine für AH, ESP) benötigt. + \item Für jede Richtung werden zwei SAs (je für AH, ESP) benötigt \end{itemize*} \item Im Tunnelmodus stellt die Nutzlast ein vollständiges IP-Paket dar % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-authentication-header.png} - \item Obwohl AH auch den äußeren IP-Header schützt, dürfen einige seiner Felder nicht geschützt werden, da sie sich während der Übertragung ändern können: + \item Obwohl AH auch den äußeren IP-Header schützt, dürfen einige seiner Felder nicht geschützt werden, da sie sich während der Übertragung ändern können \begin{itemize*} - \item Dies gilt auch für veränderliche IPv4-Optionen oder IPv6-Erweiterungen. + \item Dies gilt auch für veränderliche IPv4-Optionen oder IPv6-Erweiterungen \item Solche Felder werden bei der Berechnung des MAC als Null angenommen - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-authentication-header-2.png} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-authentication-header-2.png} \end{itemize*} - \item Alle unveränderlichen Felder, Optionen und Erweiterungen (grau) sind geschützt - %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-AH-Ausgangsbearbeitung.png} + %\item Alle unveränderlichen Felder, Optionen und Erweiterungen (grau) sind geschützt + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-AH-outbound-processing.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-AH-prepare-header.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-AH-inbound-processing-1.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-AH-inbound-processing-2.png} \end{itemize*} - \subsection{IPsec's Verwendung von kryptographischen Algorithmen} + \subsection{IPsec's Verwendung von krypt. Algorithmen} \begin{itemize*} - \item Vertraulichkeit (nur ESP): + \item Vertraulichkeit (nur ESP) \begin{itemize*} - \item Die Verwendung von DES mit ESP wird nicht mehr empfohlen + \item Verwendung von DES mit ESP wird nicht mehr empfohlen \item AES-CBC ist vielleicht der Standardalgorithmus - \item Der Initialisierungsvektor (IV) ist immer im Klartext enthalten, um Synchronisationsprobleme zu vermeiden. + \item Der Initialisierungsvektor (IV) ist immer im Klartext enthalten, um Synchronisationsprobleme zu vermeiden \item Der gesamte IV soll zufällig sein - \item Nehmen Sie KEINE weiteren IVs aus früheren Chiffretexten! - \begin{itemize*} - \item Sicherheitsprobleme - \item Synchronisationsprobleme - \end{itemize*} + \item Nehme KEINE weiteren IVs aus früheren Chiffretexten! + %\begin{itemize*} + % \item Sicherheitsprobleme + % \item Synchronisationsprobleme + %\end{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-protect-payload.png} \end{itemize*} - \item Authentifizierung der Datenherkunft (AH und ESP): + \item Authentifizierung der Datenherkunft (AH und ESP) \begin{itemize*} - \item Einige der Algorithmen zur Authentifizierung sind bereits definiert: + \item Einige Algorithmen zur Authentifizierung bereits definiert \begin{itemize*} \item HMAC-MD5-96 mit Schlüssellänge 128 Bit \item HMAC-SHA1-96 mit Schlüssellänge 160 Bit - \item HMAC-RIPEMD160-96 mit einer Schlüssellänge von 160 Bit - \item HMAC-SHA2 mit Schlüssellängen von 256, 384 und 512 Bit + \item HMAC-RIPEMD160-96 mit 160 Bit Schlüssel + \item HMAC-SHA2 mit 256, 384 und 512 Bit Schlüssel \end{itemize*} - \item Alle diese Algorithmen verwenden definierte HMAC-Konstruktion: + \item diese Algorithmen verwenden HMAC-Konstruktion \begin{itemize*} - \item ipad = 0x36 wiederholt B mal (B = 64 für die oben genannten Algorithmen) + \item ipad = 0x36 wiederholt B=64 mal %(B = 64 für die oben genannten Algorithmen) \item opad = 0x5C, B-mal wiederholt - \item HMAC = H(Key XOR opad, H(Key XOR ipad, data)), wobei H die verwendete kryptografische Hash-Funktion angibt + \item HMAC = H(Key XOR opad, H(Key XOR ipad, data)) %wobei H die verwendete kryptografische Hash-Funktion angibt \end{itemize*} - \item Das ,,-96'' in den oben genannten Algorithmen bedeutet, dass die Ausgabe der Hash-Funktion auf die 96 ganz linken Bits gekürzt wird + \item Das ,,-96'' in Algorithmen bedeutet, dass die Ausgabe der Hash-Funktion auf die 96 ganz linken Bits gekürzt wird \item SHA2 abgeschnitten auf die Hälfte der Schlüssellänge - \item Dieser Wert erfüllt die meisten Sicherheitsanforderungen gut + \item Dieser Wert erfüllt die meisten Sicherheitsanforderungen \end{itemize*} \end{itemize*} \subsection{Aufbau von Sicherheitsassoziationen} \begin{itemize*} - \item Bevor ein Paket durch IPsec geschützt werden kann, muss eine SA zwischen den beiden ,,kryptographischen Endpunkten'', die den Schutz bieten, eingerichtet werden + \item Bevor ein Paket durch IPsec geschützt werden kann, muss eine SA zwischen den beiden kryptographischen Endpunkten, die den Schutz bieten, eingerichtet werden \item Der Aufbau einer SA kann realisiert werden \begin{itemize*} \item Manuell, durch proprietäre Methoden der Systemverwaltung \item Dynamisch, durch ein standardisiertes Authentifizierungs- und Schlüsselverwaltungsprotokoll - \item Die manuelle Einrichtung sollte nur in sehr eingeschränkten Konfigurationen (z.B. zwischen zwei verschlüsselnden Firewalls eines VPN) und während einer Übergangsphase verwendet werden + \item Die manuelle Einrichtung sollte nur in sehr eingeschränkten Konfigurationen und während einer Übergangsphase verwendet werden \end{itemize*} \item IPsec definiert eine standardisierte Methode für den SA-Aufbau \begin{itemize*} - \item Internet Security Association and Key Management Protocol (ISAKMP) - \begin{itemize*} - \item Definiert Protokollformate und Verfahren für die Sicherheitsaushandlung - \end{itemize*} - \item Internet-Schlüsselaustausch (IKE) - \begin{itemize*} - \item Definiert das Standard-Authentifizierungs- und Schlüsselaustauschprotokoll von IPsec - \end{itemize*} + \item Internet Security Association and Key Management Protocol (ISAKMP): Definiert Protokollformate und Verfahren für die Sicherheitsaushandlung + \item Internet-Schlüsselaustausch (IKE): Definiert das Standard-Authentifizierungs- und Schlüsselaustauschprotokoll von IPsec \end{itemize*} \end{itemize*} - \subsection{ISAKMP - Einführung} + \subsection{ISAKMP} \begin{itemize*} - \item Die IETF hat zwei RFCs zu ISAKMP für IPsec verabschiedet: + \item Die IETF hat zwei RFCs zu ISAKMP für IPsec verabschiedet \begin{itemize*} \item RFC 2408, der das ISAKMP-Basisprotokoll definiert - \item RFC 2407, der die ,,domain of interpretation'' (DOI) von IPsec für ISAKMP definiert und die für IPsec spezifischen Nachrichtenformate näher beschreibt + \item RFC 2407, für die ,,domain of interpretation'' (DOI) \end{itemize*} - \item Das ISAKMP-Basisprotokoll ist ein generisches Protokoll, das für verschiedene Zwecke verwendet werden kann: + \item ISAKMP-Basisprotokoll ist generisches Protokoll für verschiedene Zwecke \begin{itemize*} - \item Die für eine Anwendung von ISAKMP spezifischen Verfahren werden in einem DOI-Dokument detailliert beschrieben. - \item Es wurden weitere DOI-Dokumente erstellt: - \begin{itemize*} - \item Group DOI für sichere Gruppenkommunikation - \item MAP DOI für die Verwendung von ISAKMP zum Aufbau von SAs zur Sicherung des Mobile Application Protocol (MAP) von GSM (Internet Draft, Nov. 2000) - \end{itemize*} + \item spezifischen Verfahren in DOI-Dokument detailliert beschrieben + \item es wurden weitere DOI-Dokumente erstellt + \item Group DOI für sichere Gruppenkommunikation + \item MAP DOI für die Verwendung von ISAKMP zum Aufbau von SAs zur Sicherung des Mobile Application Protocol (MAP) von GSM \end{itemize*} \item ISAKMP definiert zwei grundlegende Kategorien von Austauschvorgängen \begin{itemize*} @@ -3936,171 +3860,160 @@ \subsubsection{ISAKMP - Grundlegendes Nachrichtenformat} \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-format.png} - \item Initiator \& Responder Cookie: - \begin{itemize*} - \item Identifizieren einen ISAKMP-Austausch bzw. eine Sicherheitsassoziation - \item Dienen auch als begrenzter Schutz gegen Denial-of-Service-Angriffe (siehe unten) - \end{itemize*} + \item Initiator \& Responder Cookie: Identifizieren einen ISAKMP-Austausch bzw. eine Sicherheitsassoziation + %\item Dienen auch als begrenzter Schutz gegen Denial-of-Service-Angriffe (siehe unten) \item Nächste Nutzlast: gibt an, welcher ISAKMP-Nutzlasttyp die erste Nutzlast der Nachricht ist \item Major \& Minor Version: gibt die Version des ISAKMP-Protokolls an - \item Austausch-Typ: - \begin{itemize*} - \item Gibt die Art des verwendeten Austauschs an - \item Es gibt fünf vordefinierte generische Austauschtypen, weitere Typen können pro DOI definiert werden - \end{itemize*} + \item Austausch-Typ: Gibt die Art des verwendeten Austauschs an + %\item Es gibt fünf vordefinierte generische Austauschtypen, weitere Typen können pro DOI definiert werden \item Flags: - \begin{itemize*} - \item Encrypt: wenn auf eins gesetzt, wird die Nutzlast nach dem Header verschlüsselt - \item Commit: wird für die Schlüsselsynchronisation verwendet - \item Authenticate only: wenn auf eins gesetzt, wird nur der Schutz der Datenursprungsauthentifizierung auf die ISAKMP-Nutzdaten angewendet und keine Verschlüsselung durchgeführt - \end{itemize*} + \begin{description*} + \item[Encrypt] wenn auf eins gesetzt, wird die Nutzlast nach dem Header verschlüsselt + \item[Commit] wird für die Schlüsselsynchronisation verwendet + \item[Authenticate only] wenn auf eins gesetzt, wird nur der Schutz der Datenursprungsauthentifizierung auf die ISAKMP-Nutzdaten angewendet und keine Verschlüsselung durchgeführt + \end{description*} \item Nachrichten-ID: Dient zur Identifizierung von Nachrichten, die zu verschiedenen Austauschen gehören \item Nachrichtenlänge: Gesamtlänge der Nachricht (Header + Payload) \item Nutzlast: \begin{itemize*} \item Die Nutzlast einer ISAKMP-Nachricht kann tatsächlich mehrere ,,verkettete'' Nutzlasten enthalten \item Der Nutzlasttyp der ersten Nutzlast in der Nachricht wird im nächsten Nutzlastfeld des ISAKMP-Headers angegeben - \item Alle ISAKMP-Nutzdaten haben einen gemeinsamen Nutzdaten-Header: - \begin{itemize*} - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload.png} - \item Next Header: der Payload-Typ des nächsten Payloads in der Nachricht - \item Payload Length: Gesamtlänge der aktuellen Payload (einschließlich dieses Headers) - \end{itemize*} + \item Alle ISAKMP-Nutzdaten haben einen gemeinsamen Nutzdaten-Header + %\begin{itemize*} + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload.png} + % \item Next Header: der Payload-Typ des nächsten Payloads in der Nachricht + % \item Payload Length: Gesamtlänge der aktuellen Payload (einschließlich dieses Headers) + %\end{itemize*} \end{itemize*} \end{itemize*} \subsubsection{ISAKMP - Begrenzter Schutz vor Denial of Service} \begin{itemize*} - \item Die Initiator- und Responder-Cookies dienen auch als Schutz gegen einfache Denial-of-Service-Angriffe - \item Authentifizierung und Schlüsselaustausch erfordern oft ,,teure'' Berechnungen, z.B. Potenzierung (für Diffie-Hellman Schlüsselaustausch) - \item Um zu verhindern, dass ein Angreifer eine ISAKMP-Einheit mit gefälschten Nachrichten von gefälschten Quelladressen überschwemmen und diese teuren Operationen verursachen kann, wird das folgende Schema verwendet: - \begin{itemize*} - \item Die initiierende ISAKMP-Entität erzeugt einen Initiator-Cookie: $CKY-I = H(Secret_{Initiator}, Address_{Responder}, t_{Initiator})$ - \item Der Responder generiert sein eigenes Cookie: $CKY-R = H(Secret_{Responder}, Address_{Initiator}, t_{Responder})$ - \item Beide Entitäten schließen immer beide Cookies ein und überprüfen immer ihr eigenes Cookie, bevor sie eine teure Operation durchführen - \item Der oben erwähnte Angriff wird daher nicht erfolgreich sein, da der Angreifer eine Antwort von dem angegriffenen System erhalten muss, um ein Cookie von ihm zu erhalten - \end{itemize*} + \item Initiator-Responder-Cookies als Schutz gegen DoS + \item Authentifizierung und Schlüsselaustausch erfordern oft ,,teure'' Berechnungen%, z.B. Potenzierung (für Diffie-Hellman Schlüsselaustausch) + \item Um zu verhindern, dass ein Angreifer eine ISAKMP-Einheit mit gefälschten Nachrichten von gefälschten Quelladressen überschwemmen und diese teuren Operationen verursachen kann, wird das folgende Schema verwendet + \item Die initiierende ISAKMP-Entität erzeugt einen Initiator-Cookie: $CKY-I = H(Secret_{Initiator}, Address_{Responder}, t_{Initiator})$ + \item Der Responder generiert sein eigenes Cookie: $CKY-R = H(Secret_{Responder}, Address_{Initiator}, t_{Responder})$ + \item Beide Entitäten schließen immer beide Cookies ein und überprüfen immer ihr eigenes Cookie, bevor sie eine teure Operation durchführen + \item Der oben erwähnte Angriff wird daher nicht erfolgreich sein, da der Angreifer eine Antwort von dem angegriffenen System erhalten muss, um ein Cookie von ihm zu erhalten \item ISAKMP spezifiziert die genaue Cookie-Erzeugungsmethode nicht \end{itemize*} \subsubsection{ISAKMP - Nutzdatenarten} \begin{itemize*} - \item RFC 2408 definiert verschiedene Nutzdaten von ISAKMP (Liste ist nicht vollständig) - \item Generische Payloads: Hash, Signatur, Nonce, Vendor ID, Schlüsselaustausch - \item Spezifische Payloads: SA, Zertifikat, Zertifikatsanforderung, Identifikation - \item Abhängige und gekapselte Nutzdaten: - \begin{itemize*} - \item Proposal-Payload: beschreibt einen Vorschlag für die SA-Verhandlung - \item Transform-Payload: beschreibt eine Transformation eines Proposals - \end{itemize*} - \item Außerdem gibt es eine generische Attribut-Nutzlast: + \item RFC 2408 definiert verschiedene Nutzdaten von ISAKMP %(Liste ist nicht vollständig) + \item Gen. Payloads: Hash, Signatur, Nonce, Vendor ID, Schlüsselaustausch + \item Spez. Payloads: SA, Zertifikat, Zertifikatsanforderung, Identifikation + \item Abhängige und gekapselte Nutzdaten + \begin{description*} + \item[Proposal-Payload] beschreibt Vorschlag für die SA-Verhandlung + \item[Transform-Payload] beschreibt Transformation eines Proposals + \end{description*} + \item Außerdem gibt es eine generische Attribut-Nutzlast \begin{itemize*} \item Dies ist eigentlich kein ISAKMP-Payload, sondern ein Payload, der innerhalb der ISAKMP-Payloads erscheint. \item Alle Attribut-Payloads haben eine gemeinsame Struktur - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload-types.png} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload-types.png} \end{itemize*} \end{itemize*} \subsubsection{ISAKMP - Die Sicherheits-Assoziations-Nutzdaten} \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-security-payload.png} - \item Domain of Interpretation definiert die Anwendungsdomäne für die auszuhandelnde SA, z.B. IPsec - \item Situation ist ein DOI-spezifisches Feld, das die Situation angibt, in der die aktuelle Verhandlung stattfindet (z.B. Notruf vs. normaler Anruf) + \item Domain of Interpretation definiert die Anwendungsdomäne für die auszuhandelnde SA%, z.B. IPsec + \item Situation ist ein DOI-spezifisches Feld, das die Situation angibt, in der die aktuelle Verhandlung stattfindet %(z.B. Notruf vs. normaler Anruf) \item Auf den SA-Payload folgen ein oder mehrere Proposal-Payloads \end{itemize*} \subsubsection{ISAKMP - Die Vorschlagsnutzdaten} \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-proposal-payload.png} - \item Proposal \# wird verwendet, um Richtlinien auszudrücken und Vorschläge auszuhandeln: + \item Proposal \# wird verwendet, um Richtlinien auszudrücken und Vorschläge auszuhandeln \begin{itemize*} - \item Wenn zwei oder mehr Vorschläge die gleiche Nummer tragen, wird ein logisches UND realisiert. + \item Wenn zwei oder mehr Vorschläge die gleiche Nummer tragen, wird ein logisches UND realisiert \item Unterschiedliche Werte für Proposal \# realisieren logisches OR mit absteigender Priorität \end{itemize*} - \item Protocol ID gibt den Protokoll-Identifikator der aktuellen Verhandlung an, z.B. AH oder ESP (für IPsec) + \item Protocol ID gibt den Protokoll-Identifikator der aktuellen Verhandlung an%, z.B. AH oder ESP (für IPsec) \item SPI Size gibt die Länge des enthaltenen SPI-Wertes an - \item Number of Transforms (Anzahl der Transformationen) gibt an, wie viele Transformationen zu diesem Vorschlag gehören (diese folgen unmittelbar auf die Nutzlast des Vorschlags) + \item Number of Transforms gibt an, wie viele Transformationen zu diesem Vorschlag gehören %(diese folgen unmittelbar auf die Nutzlast des Vorschlags) \end{itemize*} \subsubsection{ISAKMP - Die Transformations-Nutzdaten} \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-transform-payload.png} - \item Eine Transform-Payload spezifiziert einen bestimmten Sicherheitsmechanismus, auch Transform genannt, der zur Sicherung des Kommunikationskanals verwendet werden soll. + \item Eine Transform-Payload spezifiziert einen bestimmten Sicherheitsmechanismus, auch Transform genannt, der zur Sicherung des Kommunikationskanals verwendet werden soll \item Jede in einem Vorschlag aufgeführte Transformation hat eine eindeutige Transform \# - \item Jede Transformation wird durch eine Transform-ID eindeutig identifiziert, z.B. 3DES, AES, MD5, SHA-1, etc. + \item Jede Transformation wird durch eine Transform-ID eindeutig identifiziert%, z.B. 3DES, AES, MD5, SHA-1, etc. \item Die Transformations-IDs werden in einem DOI-Dokument angegeben - \item Die SA-Attribute geben die Attribute an, die für die im Feld Transform ID angegebene Transformation definiert sind. + \item Die SA-Attribute geben die Attribute an, die für die im Feld Transform ID angegebene Transformation definiert sind \end{itemize*} \subsubsection{ISAKMP - SA-Verhandlung} \begin{itemize*} \item Inhalt des Next Payload-Feldes von SA-, Proposal- und Transform-Payloads: \begin{itemize*} - \item Das Next-Payload-Feld einer SA-Payload gibt nicht die unmittelbar folgende Proposal-Payload an, da diese implizit ist. + \item Das Next-Payload-Feld einer SA-Payload gibt nicht die unmittelbar folgende Proposal-Payload an, da diese implizit ist \item Das Gleiche gilt für Proposal- und Transform-Payloads \end{itemize*} - \item Die Proposal-Payload gibt der initiierenden Entität die Möglichkeit, der antwortenden Entität die Sicherheitsprotokolle und zugehörigen Sicherheitsmechanismen zur Verwendung mit der auszuhandelnden Sicherheitsassoziation zu präsentieren. - \item Wenn die SA-Etablierung für eine kombinierte Schutzsuite ausgehandelt wird, die aus mehreren Protokollen besteht, muss es mehrere Proposal-Payloads geben, die jeweils die gleiche Proposal-Nummer haben. - \item Diese Vorschläge müssen als eine Einheit betrachtet werden und dürfen nicht durch einen Vorschlag mit einer anderen Vorschlagsnummer getrennt werden. - \item Dieses erste Beispiel zeigt eine ESP- UND AH-Schutzsuite: - \begin{itemize*} - \item Das erste Protokoll wird mit zwei von der vorschlagenden Stelle unterstützten Transformationen dargestellt, ESP mit: - \begin{itemize*} - \item Transformation 1 als 3DES - \item Umwandlung 2 als AES - \item Der Responder muss zwischen den beiden für ESP vorgeschlagenen Transformationen wählen. - \end{itemize*} - \item Das zweite Protokoll ist AH und wird mit einer einzigen Transformation angeboten: - \begin{itemize*} - \item Umwandlung 1 als SHA - \end{itemize*} - \item Die resultierende Schutzsuite ist entweder - \begin{itemize*} - \item 3DES und SHA, oder - \item AES und SHA, je nachdem, welche ESP-Transformation vom Responder gewählt wurde - \end{itemize*} - \item In diesem Fall folgen auf die SA-Nutzdaten die folgenden Nutzdaten: - \begin{itemize*} - \item ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2, AES)'' ,,Vorschlag 1, AH, (Transform 1, SHA)'' - \end{itemize*} - \item Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt! - \end{itemize*} - \item Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene - Schutzsuiten: - \begin{itemize*} - \item Die erste Schutzsuite wird vorgestellt mit: - \begin{itemize*} - \item einer Transformation (MD5) für das erste Protokoll (AH), und - \item eine Umwandlung (3DES) für das zweite Protokoll (ESP) - \end{itemize*} - \item Die zweite Schutzsuite wird mit zwei Transformationen für ein einziges Protokoll (ESP) vorgestellt: 3DES, oder AES - \item Bitte beachten Sie, dass es nicht möglich ist, festzulegen, dass Transformation 1 und Transformation 2 für eine Instanz einer Protokollspezifikation verwendet werden müssen. - \item In diesem Fall folgen auf den SA-Payload die folgenden Payloads: - \begin{itemize*} - \item ,,Vorschlag 1, AH, (Transform 1, MD5, ...)'' ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...)'' ,,Vorschlag 2, ESP, (Transform1, 3DES, ...), (Transform 2, AES, ...)'' - \end{itemize*} - \item Bitte beachten Sie, dass Vorschlag 1 zu zwei SAs pro Richtung führt. - \end{itemize*} + \item Die Proposal-Payload gibt der initiierenden Entität die Möglichkeit, der antwortenden Entität die Sicherheitsprotokolle und zugehörigen Sicherheitsmechanismen zur Verwendung mit der auszuhandelnden Sicherheitsassoziation zu präsentieren + \item Wenn die SA-Etablierung für eine kombinierte Schutzsuite ausgehandelt wird, die aus mehreren Protokollen besteht, muss es mehrere Proposal-Payloads geben, die jeweils die gleiche Proposal-Nummer haben + \item Diese Vorschläge müssen als eine Einheit betrachtet werden und dürfen nicht durch einen Vorschlag mit einer anderen Vorschlagsnummer getrennt werden + %\item Dieses erste Beispiel zeigt eine ESP- UND AH-Schutzsuite + %\begin{itemize*} + % \item Das erste Protokoll wird mit zwei von der vorschlagenden Stelle unterstützten Transformationen dargestellt, ESP mit: + % \begin{itemize*} + % \item Transformation 1 als 3DES + % \item Umwandlung 2 als AES + % \item Der Responder muss zwischen den beiden für ESP vorgeschlagenen Transformationen wählen. + % \end{itemize*} + % \item Das zweite Protokoll ist AH und wird mit einer einzigen Transformation angeboten: + % \begin{itemize*} + % \item Umwandlung 1 als SHA + % \end{itemize*} + % \item Die resultierende Schutzsuite ist entweder + % \begin{itemize*} + % \item 3DES und SHA, oder + % \item AES und SHA, je nachdem, welche ESP-Transformation vom Responder gewählt wurde + % \end{itemize*} + % \item In diesem Fall folgen auf die SA-Nutzdaten die folgenden Nutzdaten: + % \begin{itemize*} + % \item ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2, AES)'' ,,Vorschlag 1, AH, (Transform 1, SHA)'' + % \end{itemize*} + % \item Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt! + %\end{itemize*} + %\item Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene Schutzsuiten: + %\begin{itemize*} + % \item Die erste Schutzsuite wird vorgestellt mit: + % \begin{itemize*} + % \item einer Transformation (MD5) für das erste Protokoll (AH), und + % \item eine Umwandlung (3DES) für das zweite Protokoll (ESP) + % \end{itemize*} + % \item Die zweite Schutzsuite wird mit zwei Transformationen für ein einziges Protokoll (ESP) vorgestellt: 3DES, oder AES + % \item Bitte beachten Sie, dass es nicht möglich ist, festzulegen, dass Transformation 1 und Transformation 2 für eine %Instanz einer Protokollspezifikation verwendet werden müssen. + % \item In diesem Fall folgen auf den SA-Payload die folgenden Payloads: + % \begin{itemize*} + % \item ,,Vorschlag 1, AH, (Transform 1, MD5, ...)'' ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...)'' ,,Vorschlag 2, ESP, (Transform1, 3DES, ...), (Transform 2, AES, ...)'' + % \end{itemize*} + % \item Bitte beachten Sie, dass Vorschlag 1 zu zwei SAs pro Richtung führt. + %\end{itemize*} \item Bei der Beantwortung einer Security-Association-Nutzlast muss der Antwortende eine Security-Association-Nutzlast mit dem ausgewählten Vorschlag senden, der aus mehreren Proposal-Nutzlasten und den zugehörigen Transform-Nutzlasten bestehen kann - \item Jede der Proposal-Payloads muss eine einzelne Transform-Payload enthalten, die dem Protokoll zugeordnet ist. - \item Der Antwortende sollte das Feld Proposal \# in der Proposal-Payload und das Feld Transform \# in jeder Transform-Payload des ausgewählten Vorschlags beibehalten. + \item Jede der Proposal-Payloads muss eine einzelne Transform-Payload enthalten, die dem Protokoll zugeordnet ist + \item Der Antwortende sollte das Feld Proposal \# in der Proposal-Payload und das Feld Transform \# in jeder Transform-Payload des ausgewählten Vorschlags beibehalten \begin{itemize*} - \item Die Beibehaltung der Vorschlags- und Transformationsnummern sollte die Protokollverarbeitung des Initiators beschleunigen, da die Auswahl des Antwortenden nicht mit jeder angebotenen Option verglichen werden muss. - \item Diese Werte ermöglichen es dem Initiator, den Vergleich direkt und schnell durchzuführen. + \item Die Beibehaltung der Vorschlags- und Transformationsnummern sollte die Protokollverarbeitung des Initiators beschleunigen, da die Auswahl des Antwortenden nicht mit jeder angebotenen Option verglichen werden muss + \item Diese Werte ermöglichen es dem Initiator, den Vergleich direkt und schnell durchzuführen \end{itemize*} \item Der Initiator muss überprüfen, ob die vom Responder empfangene SA-Nutzlast mit einem der ursprünglich gesendeten Vorschläge übereinstimmt \end{itemize*} \subsubsection{ISAKMP - Session Key Establishment} \begin{itemize*} - \item ISAKMP baut 4 verschiedene Schlüssel mit einem Authentifizierungsaustausch auf: - \begin{itemize*} - \item SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist und als ,,Hauptschlüssel'' dient. - \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode - \item SKEYID\_e ist das Schlüsselmaterial, das von der ISAKMP SA zum Schutz der Vertraulichkeit ihrer Nachrichten verwendet wird - \item SKEYID\_a ist das Schlüsselmaterial, das von der ISAKMP SA zur Authentifizierung ihrer Nachrichten verwendet wird - \item SKEYID\_d ist das Verschlüsselungsmaterial, das zur Ableitung von Schlüsseln für Nicht-ISAKMP-Sicherheitsassoziationen verwendet wird. - \end{itemize*} + \item ISAKMP baut 4 verschiedene Schlüssel mit einem Authentifizierungsaustausch auf + \item SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist und als ,,Hauptschlüssel'' dient + \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode + \item SKEYID\_e ist das Schlüsselmaterial, das von der ISAKMP SA zum Schutz der Vertraulichkeit ihrer Nachrichten verwendet wird + \item SKEYID\_a ist das Schlüsselmaterial, das von der ISAKMP SA zur Authentifizierung ihrer Nachrichten verwendet wird + \item SKEYID\_d ist das Verschlüsselungsmaterial, das zur Ableitung von Schlüsseln für Nicht-ISAKMP-Sicherheitsassoziationen verwendet wird \end{itemize*} \subsection{IKE - Einführung}