Netzsicherheit 14: IPSec

Transkript

1 Netzsicherheit 14: IPSec Das TCP/IP-Schichtenmodell Anwendungsschicht (FTP, HTTP, SMTP,...) Transportschicht (TCP, UDP) Internetschicht (IP) Netzwerkschicht (z.b. Ethernet, WLAN,...) IPSec Beobachtung: IP ist das einzige Protokoll, das im Internet durchgängig verwendet wird. Session 2 / 1

2 Das Internet Protokoll (IP) 1969 DARPA (Defense Advanced Research Project Agency) entwickelt ARPANET 1974 Entwicklung von TCP/IP 1975 Integration von TCP/IP in Berkeley Unix Ab 80 Anschluss vieler Unis über das National Science Foundation NET 1983 Trennung MILNET und ARPANET/Internet 1990 Auflösung des ARPANET 1992 Gründung der Internet Society mit dem Standardisierungsgremium Internet Engineering Task Force (IETF) Das Internet Protokoll (IP) IP-Pakete werden von IP Source über mehrere Router hinweg nach IP Dest transportiert. keine feste Route Reihenfolge aufeinanderfolgender Pakete kann verändert werden IP-Pakete können verloren gehen Router handeln dezentral die Routen aus IP-Pakete werden von Routern gelöscht, wenn TTL=0 gilt Hilfsprotokolle: Internet Control Message Protocol (ICMP): Fehlermeldungen etc. Adress Resolution Protocol (ARP): Zuordnung MAC zu IP Domain Name System (DNS): Zuordnung DNS-Name zu IP Diverse Routing-Protokolle Session 2 / 2

3 Das Internet Protokoll (IP) Routing (Quelle: Tanenbaum) A Das Internet Protokoll (IP) IP-Adressklassen 0 Netzwerk Host Host Host B 1 0 Netzwerk Netzwerk Host Host C Netzwerk Netzwerk Netzwerk Host IP Multicast Experimentelle Netze Session 2 / 3

4 Das Internet Protokoll (IP) Beispiel: Die IP-Adresse von = = Diese Adresse gehört zu einem Klasse C-Netz Netze können mit Subnetzmasken in Subnetze zerlegt werden Adressklasse Erstes Oktett Anzahl Netze Hosts / Netz A B * C * Multicast Experimentell Das Internet Protokoll (IP): NAT Network Address Translation (NAT) RFC 1918: Address Allocation for Private Internets The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: (10/8 prefix) (172.16/12 prefix) ( /16 prefix) Das Paar (Private IP-Adresse, Portnummer) wird durch NATP- Gateway durch (Offizielle IP-Adresse, freie Portnummer) ersetzt Session 2 / 4

5 Das Internet Protokoll (IP): NAT src NAT Router src Dynamic NAT-Table src src dst dst Private IP- Adresse wird durch öffentl. Adresse aus Pool ersetzt Dynamic NAT-Table Internal IP External IP Harald Schultz 2002 Das Internet Protokoll (IP): NATP src :1257 N A T R o u te r src :63400 dst :80 dst :80 M a sq u e ra d in g -T a b le src :4325 src :63401 dst :23 dst :23 Pool enthält nur eine öffentl. Adresse, Private IP-Adresse wird durch öffentl. Adresse + zufällig gewählte (eindeutige) Portnummer ersetzt M asquerading - Table In te rn a l IP /P o rt L o ca l N A T -P o rt : : Harald Schultz 2002 Session 2 / 5

6 IP (2) IP (3) Session 2 / 6

7 Hybride Verschlüsselung für IP? IP-Nutzlast wird symmetrisch verschlüsselt Verwendeter Schlüssel wird asymmetrisch verschlüsselt (RSA) in neuem Header transportiert Hybride Verschlüsselung für IP? (2) Nein! Public-Key-Kryptogramme sind zu lang: RSA-Kryptogramm ohne Zusatzinfo: Bit, d.h Byte. Mit notwendiger Zusatzinfo (Zertifikatskette) leicht 1000 Byte. Maximal Transfer Unit (MTU) liegt wegen Ethernet-Strecken oft nur bei 1500 Byte. Session 2 / 7

8 SKIP (1) SKIP wird (heute noch?) von SUN unter dem Produktnamen SunScreen SKIP angeboten. Unter Solaris und Windows verfügbar. Entwicklungen wurden weitgehend eingestellt. (Die jüngsten technischen Papiere datieren von 1998.) SKIP kann mit den Datenformaten ESP und AH zusammenarbeiten. Dabei bleiben aber die Nachteile (s.u.) erhalten, Vorteile sind gegenüber IKE nicht zu erkennen. SKIP (2) SKIP: Simple Key management for Internet Protocols basiert auf der Diffie-Hellman-Schlüsselvereinbarung A kennt a g a g b B kennt b K = (g b ) a = g ab K = (g a ) b = g ab Session 2 / 8

9 SKIP (3) g a und g b werden in gemeinsamer Datenbank gespeichert Shared secret von A und B: g ab mod p A (g b ) a = (g a ) b = g ab B Privater Schlüssel: a Privater Schlüssel: b g a g b g a g b A: g a B: g b Datenbank aller öffentlichen Schlüssel SKIP (4): Ableitung der Schlüssel g ab mod p K ab Die 40 bis 128 Least Significant Bits bilden den Startwert K ab =Kij0 einer Schlüsselfolge Nach Ablauf einer festgelegten Lebensdauer wird Kij(n+1) mit Hilfe einer Hashfunktion aus Kijn gebildet Session 2 / 9

10 SKIP (5) : Header SKIP (6): Ableitung der Schlüssel Der mit Hilfe von Kijn entschlüsselte Wert Kp aus dem SKIP-Header wird verwendet, um Verschlüsselungs- und Authentisierungsschlüssel abzuleiten CryptAlg Kp MACAlg 02h hash hash 00h 03h hash hash 01h E Kp E Kp A Kp A Kp Session 2 / 10

11 SKIP (7) Probleme: SKIP setzt funktionierende PKI voraus, insbesondere eine Datenbank aller öffentlichen Schlüssel SKIP-Header ist zu groß IPSec Nahezu alle zwischen zwei Hosts ausgetauschten Daten werden verschlüsselt. IP ist verbindungslos, d.h. alle Sicherheitsparameter müssen im IP-Paket stehen Idee: Nur Referenz auf Datenbankeintrag, der den Schlüssel enthält, steht im IP-Paket. Schlüsselmanagement: Separate Applikation, die einen Datenbankeintrag generiert IPSec: IETF RFCs 1828, 1829, 2085, 2104, , 2451, 2857, 4306,... ( B2B-Projekte (ANX, ENX), viele große und kleine Hersteller (Cisco) Session 2 / 11

12 Warum Sicherheit auf IP-Ebene? Internet-Protokoll (IP) ist das meistbenutzte Netzprotokoll IP ist für alle Dienste und alle Netzwerke duchgängig: Netzwerke: IP über Ethernet, PPP/ISDN, X.25, ATM, Frame Relay,... Dienste: IP unter TCP, UDP Absicherung ist Applikations-unabhängig Einsatzgebiete LAN2LAN (Tunnel) Host2LAN (Tunnel) Host2Host (Transport) Session 2 / 12

13 Tunnel- und Transportmodus Transportmodus Es werden Pakete höherer Protokolle (TCP/UDP,...) als Payloads gesichert Effizient, da keine Kapselung von IP-Paketen Möglich, solange kein Gateway als Anfangs- oder Endpunkt der Kommunikationsbeziehung auftritt Tunnelmodus Es werden IP-Pakete als Payloads gesichert Kapselung von IP-Paketen bedeutet Overhead Wird benötigt sobald ein Gateway als Anfangs- und/oder Endpunkt der Kommunikationsbeziehung auftritt IPSec: Datenformate Transportmodus ESP Originaler IP-Header Daten Originaler IP-Header ESP-Header Daten Padding ESP-Auth. Tunnelmodus ESP Originaler IP-Header Daten Neuer IP-Header ESP-Header Originaler IP-Header Daten Padding ESP-Auth. Session 2 / 13

14 IPSec: Datenformate Aufbau des Encapsulation Security Payload (RFC 2406) IP-Header Security Parameters Index (SPI) Sequence Number Field Payload Data (variable) authentisch vertraulich Padding (0-255 Bytes) Pad Length Authentication Data (variable) Next Header Formate: AH, Tunnel- und Transportmodus Transportmodus AH Originaler IP-Header Daten Originaler IP-Header AH-Header Daten Tunnelmodus AH Authentifiziert (bis auf veränderliche Felder des IP-Headers) Originaler IP-Header Daten Neuer IP-Header AH-Header Originaler IP-Header Daten Authentifiziert (bis auf veränderliche Felder des neuen IP-Headers) Session 2 / 14

15 Formate: AH, Tunnel- und Transportmodus Authentication Header: Behandlung der zu authentisierenden Felder des IP-Headers IPSec-Formate: AH (Authentication Header) Ziele des AH (RFC 2402) kryptographische Prüfsumme über den Payload und (fixe) Teilen des IP-Headers IP-Header Next Header Payload Length RESERVED Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) Daten Session 2 / 15

16 IPv6: Datenformate IPv6 IPv6-Adressen sind 128 Bit lang. Zur Verdeutlichung: Man könnte mit Werten jedem Quadratmillimeter der Erdoberfläche ungefähr IPv6-Adressen zuweisen. IPSec integraler Bestandteil des Standards Anstelle eines komplexen Headers ein einfacher IPv6-Header und viele verschiedene Erweiterungsheader ESP und AH sind zwei dieser Erweiterungsheader IPv6-Header Erweiterungs- Header ESP-Header Daten Padding ESP-Auth. IPSec Bestandteile einer IPSec-Implementierung IKE TCP/IP SAD AH/ESP SPD TCP/IP Session 2 / 16

17 Schlüsselvereinbarung mit ISAKMP/IKE Security Association Database (SAD) Verwaltet ausgehandelte kryptographische Parameter Schlüssel Hash- und Verschlüsselungsalgorithmen Modus (ESP oder AH) Lebensdauer der SA Einträge sortiert nach IP-Adressen der anderen Hosts SPI zur Unterscheidung von SAs auf dem gleichen Host (wird vom empfangenden Host gewählt) Session 2 / 17

18 Empfangene IPSec-Pakete IKE IP SAD AH/ESP SPD 1. Anhand der Absendeadresse und der SPI des empfangenen IPSec- Pakets werden aus der SAD die kryptographischen Parameter gelesen. TCP/IP 2. Das IP-Paket wird entschlüsselt/verifiziert und an den TCP/IP-Stack übergeben. Security Policy Database (SPD) Legt fest, wie mit zu sendenden IP-Paketen zu verfahren ist unverschlüsselt senden, verwerfen oder mit SPI x verschlüsselt senden. Unterschiedliche Policies für gleiche Zieladresse möglich Auswahl anhand höherer Protokolle, z.b. UDP Port 500 (IKE) unverschlüsselt senden Session 2 / 18

19 Zu sendende IPSec-Pakete IKE TCP/IP 1. Anhand der Zieladresse des IP- Pakets (und ggf. anderer Parameter) wird in der SPD ermittelt, wie weiter zu verfahren ist, und welche SPI zu verwenden ist. SAD AH/ESP SPD 2. Anhand der von der SPD gelieferten SPI werden aus der SAD die kryptographischen Parameter gelesen. IP 3. Das verschlüsselte IP-Paket wird an den IP-Stack übergeben. Schlüsselvereinbarung mit ISAKMP/IKE 1. Mit IKE wird ein sicherer, bidirektionaler ISAKMP- Tunnel aufgebaut ( Eintrag bidirektionale SA in SAD). IKE TCP/IP 2. Innerhalb dieses Tunnels wird mit IKE je eine SA für jede Richtung ausgehandelt ( Eintrag zweier unidirektionaler SAs in SAD) SAD AH/ESP SPD IP Session 2 / 19

20 IKE (Internet Key Exchange Protocol) Standardisiert bei der IETF (RFC 2409) Setzt sich zusammen aus folgenden Protokollen: ISAKMP (Internet Security Association and Key Management Protocol, RFC 2408) OAKLEY (Key Determination Protocol, RFC 2412) DoI (The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407) IKE (The Internet Key Exchange, RFC 2409) insgesamt ca Byte Spezifikation Geschichte von IKE (1) Basiert auf: Diffie-Hellman-Schlüsselvereinbarung A kennt a g a g b B kennt b K = (g b ) a = g ab K = (g a ) b = g ab Session 2 / 20

21 Geschichte von IKE (2) Station-to-Station-Protokoll (Diffie, van Oorschot und Wiener) Löst das Man-in-the-Middle-Problem von DH Geschichte von IKE (3) Photuris (RFC 2522, Karn und Simpson) Einsatz von (stateless) Cookies zum Schutz gegen Denial-of- Service-Angriffe Session 2 / 21

22 Geschichte von IKE (4) SKEME (Krawzyk 1996) Authentisierung ohne digitale Signaturen Bei mehrmaligem DH-Austausch höhere Performance, da SHARE nur einmal benötigt wird Geschichte von IKE (5) SKEME (Krawzyk 1996) Phasen können auch verschachtelt werden Session 2 / 22

23 Geschichte von IKE (6) OAKLEY (RFC 2412, Orman): Kombination aus Photuris, SKEME, STS Datenfeld CKY-I CKY-R MSGTYPE GRP g^x (or g^y) EHAO EHAS IDP ID(I), ID(R) Ni, Nr Beschreibung Cookie des Initiators Cookie des Responders Typ der nachfolgenden Nachricht: ISA_KE&AUTH_REQ oder ISA_KE&AUTH_REP bei Schlüsselaustausch, ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP beim Aushandeln einer neuen Diffie-Hellman-Gruppe. Name/Bezeichnung der verwendeten Diffie-Hellman-Gruppe DH-Nachricht als ganze Zahl beliebiger Länge ( multiprecision integer ) Liste mit angebotenen Verschlüsselungs-, Hash- und Authentisierungs algorithmen ( Encryption Hash Authentication Offering ) Auswahl jeweils eines Verschlüsselungs-, Hash- und Authentisierungs algorithmus ( Encryption Hash Authentication Selection ) Flag das angibt, ob die Daten hinter der Verschlüsselungsgrenze verschlüsselt sind (IDP, 1) oder nicht (NIDP, 0) Identität von Initiator bzw. Responder Zufallszahl ( nonce ) von Initiator bzw. Responder Geschichte von IKE (7) OAKLEY (RFC 2412, Orman) Session 2 / 23

24 Geschichte von IKE (8) OAKLEY: Feste Felder, Authentisierung aus STS oder SKEME, Einsatz von Cookies (Photuris) für 2 verschiedene Zwecke Geschichte von IKE (9) OAKLEY: 3 Primzahlgruppen und 2 EC-Gruppen sind standardisiert Session 2 / 24

25 ISAKMP Ehrgeiziges Ziel: ISAKMP soll FÜR ALLE Schlüsselvereinbarungen im Internet genutzt werden Stellt Protokollrahmen mit bestimmten Nachrichtenformaten bereit UDP Port 500 Ansatz: 2-Phasen-Modell Phase 1: Aufbau eines sicheren Kanals zwischen 2 Instanzen Parteien authentifizieren sich gegenseitig ISAKMP-SA (Security Associations) wird etabliert Phase 2: Aufbau von SAs für Clienten Benutzung der Phase1-SA als sicheren Kanal Etablierung von IPSec SAs ISAKMP (2) ISAKMP Phase 1: Keine SA zur Verschlüsselung Originaler IP-Header UDP 500 ISAKMP Daten ISAKMP Phase 2: ISAKMP-SA zur Verschlüsselung Originaler IP-Header UDP 500 ISAKMP Daten IPSec: IPSec-SA zur Verschlüsselung Neuer IP-Header ESP-Header Originaler IP-Header Daten Padding ESP-Auth. Session 2 / 25

26 ISAKMP (3) ISAKMP (4) Session 2 / 26

27 ISAKMP (5) ISAKMP-Felder Next Payload Type Value NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED Private USE Internet Key Exchange (IKE) ISAKMP und OAKLEY bieten zu viele Optionen: Interoperabilität kann nicht gewährleistet werden ISAKMP-Dokument ist unlesbar ISAKMP muss mit einem Domain of Interpretation: IP -Dokument an IPSec angepasst werden OAKLEY erlaubt zu viele verschiedene Modi, und Kombinationen dieser Modi IKE (RFC 2409, 41 Seiten): Auswahl verschiedener Optionen, und Beschränkung auf diese ISAKMP (RFC 2408, 86 Seiten) DOI-IP (RFC 2407, 32 Seiten) OAKLEY (RFC 2412, 55 Seiten) In Summe: 214 Seiten Spezifikation Session 2 / 27

28 IKE Phase 1 Main Mode IKE Phase 1 Main Mode (2) Session 2 / 28

29 IKE Phase 1 Main Mode (3) IKE Phase 2 Quick Mode Session 2 / 29

30 IKE Phase 2 Quick Mode Aussagen zur Interoperabilität Web-basiertes Test-Tool des amerikanischen NIST Interoperabilitätstests bei der ICSA (International Computer Security Association) aktueller Kompatibilitätsstand: 1.0D Interoperabilität mit Zertifikaten: 1.1 (nur wenige Zertifizierungen) Virtual Private Network Consortium Profiling Use of PKI in IPSEC (pki4ipsec) Session 2 / 30

31 Network Address Translation (NAT) Probleme NA(P)T - IPSec (RFC 3715) Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudoheader" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device. As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). Network Address Translation (NAT) Probleme NA(P)T - IPSec (RFC 3715) Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets. In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userids and FQDNs can be used instead. Incompatibility between fixed IKE source ports and NAPT. Incompatibilities between overlapping SPD entries and NAT. Incompatibilities between IPsec SPI selection and NAT. Incompatibilities between embedded IP addresses and NAT. 6 weitere Problemfelder Session 2 / 31

32 Network Address Translation (NAT) Lösung: RFC 3947 Negotiation of NAT-Traversal in the IKE. RFC 3948 UDP Encapsulation of IPsec ESP Packets. Network Address Translation (NAT) RFC 3947 Negotiation of NAT-Traversal in the IKE. IKE-Implementierung signalisiert Support für NAT-Detection, indem sie in IKE als zusätzliches Payload MD5(RFC 3947) mitsendet. NAT-D = Next Payload RESERVED Payload length HASH(CKY-I CKY-R IP Port) Erstes NAT-D-Paket enthält Hash von Zielport und Zieladresse, zweites NAT-D-Paket von Quellport und Quelladresse Session 2 / 32

33 Network Address Translation (NAT) RFC 3947 Negotiation of NAT-Traversal in the IKE. Initiator Responder HDR, SA, VID --> <-- HDR, SA, VID HDR, KE, Ni, NAT-D, NAT-D --> <-- HDR, KE, Nr, NAT-D, NAT-D HDR*#, IDii, [CERT, ] SIG_I --> <-- HDR*#, IDir, [CERT, ], SIG_R Network Address Translation (NAT) RFC 3948 UDP Encapsulation of IPsec ESP Packets. Transport Mode BEFORE APPLYING ESP/UDP IPv4 orig IP hdr (any options) TCP Data AFTER APPLYING ESP/UDP IPv4 orig IP hdr UDP ESP ESP ESP (any options) Hdr Hdr TCP Data Trailer Auth <----- encrypted ----> < authenticated -----> Session 2 / 33

34 Network Address Translation (NAT) RFC 3948 UDP Encapsulation of IPsec ESP Packets. Tunnel Mode BEFORE APPLYING ESP/UDP IPv4 orig IP hdr (any options) TCP Data AFTER APPLYING ESP/UDP IPv4 new h. UDP ESP orig IP hdr ESP ESP (opts) Hdr Hdr (any options) TCP Data Trailer Auth < encrypted > < authenticated > Weiterentwicklungen: IKEv2 IKEv2 (RFC 4306) Probleme mit IKE Anfällig gegen DoS-Attacken (Cookies im Aggressive Mode unwirksam) Zu langsam (3,5 bis 4,5 RTT) Zu komplex (über 4 RFCs verteilt) IKEv2 soll diese Probleme lösen Nur noch ein RFC IPSec-Verschlüsselung bereits nach 2 RTT möglich Besserer Schutz gegen DoS Integration von NAT Traversal Dead Peer Detection Session 2 / 34

35 Weiterentwicklungen: IKEv2 (RFC 4306) Notation AUTH CERT CERTREQ CP D E EAP HDR IDi IDr KE Ni, Nr N SA TSi TSr V Payload Authentication Certificate Certificate Request Configuration Delete Encrypted Extensible Authentication IKE Header Identification - Initiator Identification - Responder Key Exchange Nonce Notify Security Association Traffic Selector - Initiator Traffic Selector - Responder Vendor ID Weiterentwicklungen: IKEv2 (RFC 4306) Initiator Responder HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Initiator Responder HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} --> <-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]} Session 2 / 35

36 Sourcecode KAME Project Freie IPv6 und IPv4-IPSec-Implementierung für BSD Unix Linux FreeS/WAN Freie IPSec-Implementierung für Linux, mit einigen Problemen SSH Communications Security Führende Firma für kommerzielle IPSec-Entwicklungstools Session 2 / 36