3.2 Vermittlungsschicht Internet Protocol IP: Transport von Datenpaketen zwischen beliebigen Stationen Internet Control Message Protocol - ICMP: Transport von Informationen zur internen Netzsteuerung Dynamic Host Configuration Protocol - DHCP: dynamische Zuordnung einer IP-Adresse über einen DHCP Server Address Resolution Protocol - ARP: Ermittlung der MAC-Adresse zu gegebener IP-Adresse durch Rundruf im Lokalnetz... und weitere... NS-3.2 1
3.2.1 IPSec (RFC 2401) traditionell: IPv4 mit bekannten 4-Byte-IP-Adressen neu: IPv6: flexiblere Adressierung flexibleres Paketformat Unterstützung mobiler Rechner Sicherheit: IPSec u.a. Übergang von IPv4 zu IPv6 erfolgt laaangsam... NS-3.2 2
? Warum IP-Sicherheit angesichts sicherer Sicherungsdienste? Endsysteme können sich nicht darauf verlassen, dass Vertraulichkeit, Unversehrtheit und Authentizität über alle Teilstrecken und Zwischensysteme hinweg gewährleistet ist kein sicherer Sicherungsdienst in Lokalnetzen angesichts sicherer höherer Schichten? NS-3.2 3
? Warum IP-Sicherheit angesichts sicherer höherer Schichten? Sicherheit durch System(verwalter) garantiert, nicht von individueller Anwendung abhängig UDP ist nicht gesichert NS-3.2 4
Mit IPSec wird versucht, der folgenden Sicherheitslücken im IPv4 Herr zu werden: Ausspähen von Nutzdaten eines Pakets Manipulation von Nutz- und Verkehrsdaten eines Pakets Wiedereinspielen eines zuvor beobachteten Pakets... unter Berücksichtigung unterschiedlicher Anforderungen: Jede beteiligte Station (Sender, Empfänger, Zwischenstation) kann eine eigene Sicherheitsstrategie (security policy) praktizieren - und eintreffende Pakete verwerfen, wenn sie von einer Station mit einer schwächeren Sicherheitsstrategie stammen. NS-3.2 5
Elemente von IPSec: Sicherheitsprotokoll bestimmt Sicherungsart der Daten - 2 Alternativen: Authentication Header (AH) garantiert Unversehrtheit von Nutz- und Verkehrsdaten oder Encapsulating Security Payload (ESP) garantiert zusätzlich Vertraulichkeit von Nutzdaten (und evtl. Verkehrsdaten) NS-3.2 6
Sicherheitsassoziation (security association, SA) zwischen zwei Systemen beinhaltet Sicherheitsprotokoll und dessen Zustandsdaten für unidirektionalen sicheren Paketverkehr zwischen diesen Systemen, wird zwischen den Systemen ausgehandelt (je eine SA für jede Kommunikationsrichtung) mittels Internet Security Association and Key Managment Protocol (ISAKMP) und Internet Key Exchange (IKE) (Sicherheits"verbindung"!) NS-3.2 7
Kommunikationsendpunkt = Quell- bzw. Zielsystem eines Stroms von IP-Paketen kryptographischer Endpunkt = für die Sicherung gemäß SA zuständiges System Transportmodus Kommunikationsendpunkte = kryptographische Endpunkte Tunnelmodus Kommunikationsendpunkte kryptographische Endpunkte NS-3.2 8
3.2.1.1 Protokoll AH Paketformat eines AH-gesicherten IP-Pakets: next protocol = "AH" IP Header AH Header "TCP" oder "UDP" payload length next protocol payload length Security Parameter Index (SPI) Sequence Number Authentication Data Payload SA-Nummer im Zielsystem Folgenummer MAC für gesamtes (!) Paket (MD5, SHA-1,...) 4 bytes NS-3.2 9
Folgenummern (authentisch!) schützen vor Wiedereinspielen: für jede SA werden eigene Folgenummern ab 0 verwendet Buchführung über bereits erhaltene Nummern: Wenn die IP-Übertragung reihenfolgetreu wäre, würde eine Nummernlücke Paketverlust und ein Nummernrückschritt Wiedereinspielen anzeigen (Speichern der jeweils letzten Paketnummer würde reichen) Speichern aller empfangenen Paketnummern ist prohibitiv! Bei lange zurückliegende Lücken werden die Pakete aufgegeben - und verworfen, falls sie dennoch eintreffen. NS-3.2 10
Konkretisierung: gleitendes Fenster akzeptabler Pakete Fenstergröße L = 16 (empfohlen: 64) wird bei Eintreffen verworfen höchste bisherige Nummer: N Buchführung: N und 16 Bits speichern; beim Eintreffen von n>n: N := n beim Eintreffen von n N-L: verwerfen sonst - wenn Bit nicht gesetzt: Bit setzen - wenn Bit gesetzt: Replay entdeckt! [d.h. Bit mit Index L-1-(N-n) ] NS-3.2 11
Protokollabwicklung bei Paketempfang (sobald alle Fragmente vorhanden): ist die IP-Prüfsumme korrekt? ist die durch SPI identifizierte SA vorhanden? ist die Folgenummer-Prüfung erfolgreich? ist die Authentizitätsprüfung erfolgreich? Bei einer negativen Antwort wird das Paket wird verworfen. NS-3.2 12
Bewertung: Unversehrtheit der Nutzdaten (MAC!) Unversehrtheit der Verkehrsdaten ebenfalls, da MAC auch Quell- und Zieladresse im IP Header umfasst kein IP Spoofing Kein Wiedereinspielen von Paketen (Folgenummern!) keinerlei Vertraulichkeit keine Verbindlichkeit (wegen MAC statt digitaler Unterschrift) NS-3.2 13
3.2.1.2 Protokoll ESP ermöglicht Vertraulichkeit und/oder Unversehrtheit + Replay-Schutz (gemäß SA!) next protocol = "ESP" IP Header ESP Header Security Parameter Index (SPI) Sequence Number Initialization Vector falls CBC zum Einsatz kommt Payload (opt. encrypted: 3DES, IDEA,...) NS-3.2 ESP Trailer (+ padding) Authentication Data pad length next protocol "TCP" oder "UDP" MAC (opt.) (ohne IP Header!)
Bewertung: Vertraulichkeit der Nutzdaten durch Verschlüsselung (opt.) Unversehrtheit der Nutzdaten durch MAC (opt.) Kein Wiedereinspielen von Paketen (Folgenummern!) keine Unversehrtheit der Verkehrsdaten (IP Spoofing!) keine Verbindlichkeit (wegen MAC statt digitaler Unterschrift) NS-3.2 15
3.2.1.3 Tunnel-Modus Obiges über AH und ESP bezieht sich auf das Verhalten im Transport-Modus (nur zwischen Endsystemen), d.h. Kommunikationsendpunkte = kryptographische Endpunkte IP Header IPSec Header (AH oder ESP) Payload Beide Protokolle können auch verwendet werden im Tunnel-Modus (zwischen End- oder Zwischensystemen), d.h. Kommunikationsendpunkte kryptographische Endpunkte IP Header IPSec Header IP Header Payload NS-3.2 16
Tunnel zwischen zwei Zwischensystemen verbindet z.b. zwei (intern ungeschützte) Intranets einer Firma über das öffentliche Netz Virtuelles Privates Netz (VPN) Athen Berlin IP Header IPSec Header IP Header src = XA src = A dst = XB dst = B Payload Vorteil: SA Management nur in den Zwischensystemen NS-3.2 17
3.2.1.4 Einrichtung von Security Associations 2 Protokolle: ISAKMP - Internet Security Association and Key Management Protocol regelt Nachrichtenformate und Dialogstrukturen IKE - Internet Key Exchange regelt die kryptographischen Protokolle, die auf der technischen Basis von ISAKMP abgewickelt werden NS-3.2 18
IKE - Internet Key Exchange Bevor zwischen einem Initiator und einem Responder IPSec-SAs nach Bedarf ausgehandelt werden können ("Phase-2-Dialog"), muss mindestens eine ISAKMP-SA eingerichtet sein ("Phase-1-Dialog"). Wir nehmen zunächst an: Nach Authentisierung beider Partner i,r ist ISAKMP-SA eingerichtet und die Partner verfügen gemeinsam über 1. einen geheimen Sitzungsschlüssel für Verschlüsseln und Entschlüsseln mit E ir [.] bzw. D ir [.], 2. ein Geheimnis A ir für Authentisierungszwecke NS-3.2 19
Phase-2-Dialog: Initiator übermittelt seine Wunschliste "SA" Responder antwortet mit akzeptierten "SA'" Dialog-Nummer id kommt zum Einsatz, ferner Nonces N i, N r Initiator (vereinfacht) Responder E ir [SA, N i, H[A,id,SA,N i ]] E ir [SA', N r, H[A,id,SA',N r,n i ]] E ir [H[A,id,N r,n i ]] NS-3.2 20
Phase-1-Dialog: (Main-Mode Exchange mit öffentlichen Schlüsseln) Initiator (vereinfacht) Responder SA SA' K i [c a ], K i [i], E r [N i ], Z i K r [c b ], K r [r], E i [N r ], Z r K := H[c ab,n i,n r ] K := H[c ab,n i,n r ] K["hier ist i"] K["hier ist r"] K i = H[N i,...] c = Diffie-Hellman-Werte Z = Zertifikate NS-3.2 21
Weiterhin zu beachten: Diverse benötigte Schlüssel werden aus Master Key abgeleitet, in den c ab und/oder N i, N r eingehen. SAs werden in SA-Datenbasis gespeichert (SADB). Lokale Sicherheitsstrategie ist ebenfalls in Datenbasis gespeichert (Security Policy Database - SPD). IPSec ist kompliziert, erfordert erheblichen Verwaltungsaufwand und wird nur zögerlich eingesetzt. Subtile Sicherheitsprobleme (siehe z.b. C. Eckert) NS-3.2 22