Modul 3: IPSEC Teil 2 IKEv2

Transkript

1 Modul 3: IPSEC Teil 2 IKEv2 Teil 1: Transport- und Tunnelmode / Authentication Header / Encapsulating Security Payload Security Association (SAD, SPD), IPsec-Assoziationsmanagements Teil 2: Design-Elemente des IKE-Protokolls Das IKEv2-Protokoll M. Leischner Sicherheit in Netzen Folie 1

2 Problemstellung des Schlüsselaustauschs mit IKE Voraussetzung: asymmetrisch : Beide Kommunikationspartner besitzen eine Schlüsselpaar und sind in der Lage, den Kommunikationspartner sicher zu authentifizieren. symmetrisch : Beide Kommunikationspartner besitzen einen gemeinsamen geheimen Schlüssel und haben sich auf einen MAC-Algorithmus geeinigt. Ziel 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 der Schlüsselmaterial neu generiert wird. Perfect Forward Secrecy ist sicherzustellen. 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. M. Leischner Sicherheit in Netzen

3 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 RFCs: RFC 7296 (STD 79): Internet Key Exchange Protocol Version 2 (IKEv2), Standards Track, Obsoletes: RFC 5996, October 2014 M. Leischner Sicherheit in Netzen Folie 3

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

5 Notation (gemäß RFC 7296) 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 5

6 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 6

7 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 7

8 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 8

9 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 9

10 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 10

11 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 11

12 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 12 Sicherheit in Netzen

13 IKEv2: CREATE_CHILD_SA Initiator HDR, SK {SA, Ni, [KEi,] TSi, TSr} HDR, SK {SA, 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 13

14 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 14