Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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)
09.11.2016 10:23:45 © M. Leischner
Folie 1
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
Struktur der IPsec-relevanten RFCs Authentication Header (AH) RFC 4302 (12/05) Cryptographic Algorithm RFC 7321 (08/14) Encapsulating Security Payload (ESP) RFC 4303 (12/05) Security Protocols
Security Architecture IP RFC 4301 (12/05)
Internet Key Exchange (IKEv2) RFC 7296 (10/14)
System Overview Security Associations IP Traffic Processing and Processing
Cryptographic Algorithm RFC 4307 (12/05)
Signature Authentication in IKEv2 RFC 7427 (01/15) Generic Raw Public-Key Support for IKEv2 RFC 7670 (01/16)
Key Exchange 09.11.2016 10:33:53 © M. Leischner
Sicherheit in Netzen
Folie 2
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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.
09.11.2016 11:08:13 © M. Leischner
Sicherheit in Netzen
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 4
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
Übersicht Ablauf von IKEv2 Start: IPSec Initial_Exchange Phase 1.1
IKEv2: IKE_SA_INIT
Phase 1.2
IKEv2: IKE_AUTH
IKEv2:
IKEv2: CREATE_CHILD_SA
INFORMATIONAL
Phase 2
Create_Child_SA Exchange
IKEv1-Terminologie piggibacked
IKE_SA
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
CHILD_SA
CHILD_SA
Folie 5
CHILD_SA
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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 09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 6
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 7
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 8
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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 = gab ).
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 9
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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 09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 10
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
IKEv2: IKE_AUTH Initiator
Responder
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.
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
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“ TrafficSelector-Paar für die neue Child-SA geschützt werden soll.
Folie 11
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
Traffic Selector
Traffic Selector (IPv4 und IPv6) Traffic Selector spezifiziert Protokoll, Portbereich und Adressbereich Beispiel: TSi = (0, 0-65535,192.0.2.199 - 192.0.2.199)
TSi Quelladresse des Verkehrs, TSr Zieladresse des Verkehrs. Beispiel: Initiator sendet TSi = 198.51.100.0 /24, TSr = 192.0.2.0 /24 Responder kann bestätigen mit TSi = 198.51.100.0 /24, TSr = 192.0.2.0 /24 Oder Responder kann einschränken auf Teilmenge TSi = 198.51.100.43, TSr = 198.51.100.43
Beispiel: Mit TSi = 198.51.100.0 /24, TSr = 0.0.0.0/0 überlässt Initiator die Wahl des Remotenetzes komplett dem Responder
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 12
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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.
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 13
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
Austausch IKEv2 (IKE_INIT + IKE_AUTH) Responder
Initiator 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.
09.11.2016 10:23:45 © M. Leischner
Folie 14
Sicherheit in Netzen
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
IKEv2: CREATE_CHILD_SA Initiator
Responder
HDR, SK {SAi, Ni, [KEi,] TSi, TSr}
HDR, SK {SAr, Nr, [KEr,] TSi, TSr}
Ergebnis: neue CHILD_SA aufgebaut
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
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-SelectorPaar für die neue Child-SA SA2r enthält die vom Initiator gewählten Algorithmen für die Child-SA (TSi, TSr) „eingeschränktes“ TrafficSelector-Paar für die neue Child-SA geschützt werden soll.
Folie 15
Hochschule Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner Netzwerksysteme und TK
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
09.11.2016 10:23:45 © M. Leischner
Sicherheit in Netzen
Folie 16
