Modul 3: IPSEC Teil 2 IKEv2

Transkript

1 Modul 3: IPSEC Teil 2 IKEv2 Teil 1: Transport- und Tunnelmode Authentication Header Encapsulating Security Payload IPsec Architektur (Security Association, SAD, SPD), Teil 2: Das IKE-Protokoll (IKEv2) M. Leischner Folie 1

2 Struktur der IPsec-relevanten RFCs Authentication Header (AH) RFC 4302 (12/05) Encapsulating Security Payload (ESP) RFC 4303 (12/05) Cryptographic Algorithm RFC 7321 (08/14) Security Architecture IP RFC 4301 (12/05) Security Protocols System Overview Security Associations IP Traffic Processing and Processing Internet Key Exchange (IKEv2) RFC 7296 (10/14) Signature Authentication in IKEv2 RFC 7427 (01/15) Generic Raw Public-Key Support for IKEv2 RFC 7670 (01/16) Cryptographic Algorithm RFC 4307 (12/05) Key Exchange :33:53 M. Leischner Sicherheit in Netzen Folie 2

3 Problemstellung des Schlüsselaustauschs mit IKE Mögliche Umsetzungen des Schlüsselaustauschs: statisch: Keys und Algorithmen werden off-line vereinbart. Vorteile:?? Nachteil:?? dynamisch: Verwendung eines Schlüsselaustausch-Protokolls Was sind die Voraussetzungen, damit es funktioniert:?? Ziele des Schlüsselaustausch-Protokolls für eine SA: Einigung auf einen gemeinsamen Session-Key Einigung auf kryptographische Algorithmen Beide Kommunikationspartner müssen sicherstellen, dass das notwendige Schlüsselmaterial beim jeweiligen Partner vorhanden ist und der Kommunikationspartner noch aktiv ist Beide Kommunikationspartner müssen sicherstellen, dass das Schlüsselmaterial bei Bedarf neu generiert wird. Perfect Forward Secrecy soll sichergestellt werden. Unter Perfect Forward Secrecy (kurz Forward Secrecy) versteht man den Schutz eines (temporären) Sitzungsschlüssels, wenn der Langzeit Schlüssel kompromittiert ist. Konkret: Wenn ein Angreifer die mit einem Sitzungsschlüssel verschlüsselte Kommunikation mitschneidet, soll er nicht in der Lage sein, diese nachträglich zu entschlüsseln, auch wenn er in den Besitz des Langzeitschlüssels kommt :08:13 M. Leischner Sicherheit in Netzen

4 Internet Key Exchange (IKEv2) Protocol IKEv2 baut auf IKEv1 auf, arbeitet aber nicht mit IKEv1 zusammen. IKEv2 baut auf UDP auf. Kein zuverlässiger Transport. Retransmit eines Requests nach Time-out. Verbesserungen: Vereinfachung, da nur noch ein Modus (vorher Main/Aggressive und Quick Mode) Effektiverer Protokollablauf, da nur noch zwei Request/Response-Paare (2 RTTs) (statt neun PDUs) Nur optionaler Schutz gegen DoS durch Unterstützung von Cookies Verbesserung in Zusammenwirken mit NAT ( NAT-Traversal integraler Bestandteil) Flexiblere Authentifizierung ( Configuration Payload, Hybrid-Authentifizierung, Integration von Authentifizierungsprot. z.b. RADIUS) Dead Peer Detection (DPD) (sehr einfach gelöst durch periodisches Senden INFORMATIONAL-Requ.) Unterstützung von IPSec in mobilen Anwendungen (MOBIKE) / Wechsel IP-Adresse M. Leischner Sicherheit in Netzen Folie 4

5 Übersicht Ablauf von IKEv2 Start: IPSec Phase 1.1 IKEv2: IKE_SA_INIT Initial_Exchange Phase 1.2 Phase 2 IKEv1-Terminologie IKEv2: IKE_AUTH IKEv2: CREATE_CHILD_SA Create_Child_SA Exchange IKEv2: INF- OR- MA- TIO- NAL piggibacked IKE_SA CHILD_SA CHILD_SA CHILD_SA M. Leischner Sicherheit in Netzen Folie 5

6 Kommunikationselemente von IKEv2 Grundprinzip: Request-Response-Protokoll Request des Initiators wird durch Antwort des Responders quittiert. Exchange Bei IKEv2 gibt folgende Typen von Exchanges IKE_SA_INIT Exchange: Erzeugen der IKEv2-SA IKE_AUTH Exchange without EAP: Authentifizierung der IKEv2-SA und Erzeugung der ersten Child-SA (ohne EAP) IKE_AUTH Exchange with EAP: Authentifizierung der IKEv2-SA und Erzeugung der ersten Child-SA (Integration von EAP in den Protokollablauf) CREATE_CHILD_SA: Erzeugen oder Rekeying von Child-SAs (verschiedene Formen möglich) INFORMATIONAL Exchange: Austausch von Kontrollinformationen M. Leischner Sicherheit in Netzen Folie 6

7 Notation (gemäß RFC 7296, 1.2) Notation Payload AUTH Authentication CERT Certificate CERTREQ Certificate Request CP Configuration D Delete EAP Extensible Authentication HDR IKE header (not a payload) IDi Identification - Initiator IDr Identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association SK Encrypted and Authenticated TSi Traffic Selector - Initiator TSr Traffic Selector - Responder V Vendor ID M. Leischner Sicherheit in Netzen Folie 7

8 IKEv2: IKE_INIT Initiator Responder HDR, SAi1, KEi, Ni HDR SAr1, KEr, Nr, [CERTREQ] HDR enthält SPIs, Versionsnummern, Messages ID, Flag SAi1 angebotene kryptographische Algorithmen des Initiators für das IKE_SA SAr1, der vom Responder ausgewählte Algorithmus für das IKE_SA KEi, KEr, Key Exchange (DH-Wert) von Initiator und Responder Ni, Nr Nonce (number used only once) = Zufallszahl Ergebnis: IKE-SA etabliert, vertraulicher Kanal und Integritätsüberprüfung möglich M. Leischner Sicherheit in Netzen Folie 8

9 Erzeugung von Schlüsselmaterial In the context of the IKE SA, four cryptographic algorithms are negotiated: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). The PRF is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE SA and the Child SAs. (siehe RFC 7296) Alle verwendeten Schlüssel werden von gemeinsamen Geheimnis SKEYSEED abgeleitet. SKEYSEED = prf( Ni Nr, g^ir) g^ir ist das shared secret gemäß Diffie-Hellman ( k = g ab ). M. Leischner Sicherheit in Netzen Folie 9

10 Erzeugung von Schlüsselmaterial Ableitung der anderen Schlüssel: {SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr} = prf+ (SKEYSEED, Ni Nr SPIi SPIr) Ergebnis: Diffie-Hellman Schlüsselaustausch durchgeführt Schlüsselmaterial für das IKE_SA ist generiert ABER: Authentifizierung steht noch aus. SKEYSEED ist nicht authentifiziert, könnte also von Man-in-the_middle stammen. Aufgaben des zweiten IKE_AUTH Exchange (der verschlüsselt + integritätsgesichert abläuft): 1. Gegenseitige Authentisierung 2. Aufbau der ersten CHILD_SA M. Leischner Sicherheit in Netzen Folie 10

11 IKEv2: IKE_AUTH Initiator HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Ergebnis: Init. und Res. authentifiziert, IKE-SA + erste CHILD_SA aufgebaut. Responder IDi Mit IDi bestimmt Initiator seine Identität CERT Zertifikate oder Zertifikatsketten (erstes Zertifikat muss Public Key enthalten zum AUTH zu verifizieren CERTREQ Anforderung bevorzugter Zertifikate (Angabe akzeptierter CAs) AUTH Authentisierungsdaten SAi2 enthält die vom Initiator angebotenen Algorithmen für die Child-SA (TSi, TSr) Traffic-Selector-Paar spezifiziert den Verkehr ( Subnetze ), der durch die neue Child-SA geschützt werden soll. SAr2 enthält die vom Initiator gewählten Algorithmen für die Child-SA (TSi, TSr) eingeschränktes Traffic- Selector-Paar für die neue Child-SA geschützt werden soll. M. Leischner Sicherheit in Netzen Folie 11

12 Traffic Selector Traffic Selector (IPv4 und IPv6) Traffic Selector spezifiziert Protokoll, Portbereich und Adressbereich Beispiel: TSi = (0, , ) TSi Quelladresse des Verkehrs, TSr Zieladresse des Verkehrs. Beispiel: Initiator sendet TSi = /24, TSr = /24 Responder kann bestätigen mit TSi = /24, TSr = /24 Oder Responder kann einschränken auf Teilmenge TSi = , TSr = Beispiel: Mit TSi = /24, TSr = /0 überlässt Initiator die Wahl des Remotenetzes komplett dem Responder M. Leischner Sicherheit in Netzen Folie 12

13 IKE Authentifizierung Neben Public-Key-Signatur und shared secret Authentifizierung unterstützt IKE Authentifizierung gemäß RFC 3748 (EAP). (EAP zur Benutzerauthentifizierung gegen Server) Stets werden frische Nonce in die Berechnung von AUTH integriert. Der ganze IKE_SA_INIT request bzw response ist in die Berechnung von AUTH integriert. Hierdurch wird sichergestellt, dass die Verhandlung der Algorithmen und DH-Werte nicht durch einen Man-in-the-Middle attackiert wurde (Downgrade-Angriffe). Der Signaturalgorithmus wird über IKEv2 nicht verhandelt. M. Leischner Sicherheit in Netzen Folie 13

14 Austausch IKEv2 (IKE_INIT + IKE_AUTH) 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} IKE-SA + CHILD_SA etabliert, Kommunikationspartner authent. M. Leischner Folie 14 Sicherheit in Netzen

15 IKEv2: CREATE_CHILD_SA Initiator HDR, SK {SAi, Ni, [KEi,] TSi, TSr} HDR, SK {SAr, Nr, [KEr,] TSi, TSr} Ergebnis: neue CHILD_SA aufgebaut Responder N signalisiert Rekeying und enthält SA für die das Rekeying durchgeführt werden soll. SAi enthält die vom Initiator angebotenen Algorithmen für die Child-SA Ni neue Nonce (Zufallszahl) KEi optional neuer Key-Exchange-Wert des Initiators (DH-Wert) (TSi, TSr) optional Traffic-Selector- Paar für die neue Child-SA SA2r enthält die vom Initiator gewählten Algorithmen für die Child-SA (TSi, TSr) eingeschränktes Traffic- Selector-Paar für die neue Child-SA geschützt werden soll. M. Leischner Sicherheit in Netzen Folie 15

16 Rekeying Geheime Schlüssel sollen nur begrenzte Zeit verwendet werden Die Lifetime Policy wird durch die SPD eines jeden Endpunkts gesteuert. Es gibt zwei Methoden für Rekeying 1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange Methode 2: Initiator Responder HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr} HDR, SK {SA, Nr, [KEr,] TSi, TSr} Ergebnis: Rekeying durchgeführt M. Leischner Sicherheit in Netzen Folie 16