HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
Modul 4: IPSEC Teil 2 – IKEv2
13.11.2018 17:01:16
© M. Leischner Folie 1
Teil 1:
• Transport- und Tunnelmode
• Authentication Header
• Encapsulating Security Payload
• IPsec Architektur (Security Association, SAD, SPD),
Teil 2:
• Das IKE-Protokoll (IKEv2)
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
Key Exchange
System Overview
Security Associations
IP Traffic Processing
and Processing
Struktur der IPsec-relevanten RFCs
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 2
Security Architecture IP
RFC 4301 (12/05)
Security Protocols
Authentication Header (AH)
RFC 4302 (12/05)
Encapsulating Security
Payload (ESP)
RFC 4303 (12/05)
Cryptographic Algorithm
RFC 7321 (08/14)
Internet Key Exchange
(IKEv2)
RFC 7296 (10/14)
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)
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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.
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 4
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
IKEv1-Terminologie Create_Child_SA Exchange
Initial_Exchange
Übersicht Ablauf von IKEv2
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 5
Start: IPSec
IKEv2: IKE_SA_INIT
IKEv2: IKE_AUTH
IKEv2: CREATE_CHILD_SA
IKE_SA CHILD_SA CHILD_SA CHILD_SA
Phase 1.1
Phase 1.2
Phase 2
piggibacked
IKEv2:
INF-
OR-
MA-
TIO-
NAL
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
Kommunikationselemente von IKEv2
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 6
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
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 7
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
IKEv2: IKE_INIT
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 8
Initiator Responder
Ergebnis: IKE-SA etabliert,
vertraulicher Kanal und Integritäts-
überprüfung möglich
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
HDR, SAi1, KEi, Ni
HDR SAr1, KEr, Nr, [CERTREQ]
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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 GeheimnisSKEYSEED abgeleitet.
SKEYSEED = prf( Ni|Nr, g^ir)
g^ir ist das shared secret gemäß Diffie-Hellman ( k = gab ).
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 9
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 10
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
IKEv2: IKE_AUTH
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 11
Initiator Responder
Ergebnis: Init. und Res. authentifiziert,
IKE-SA + erste CHILD_SA aufgebaut.
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.
HDR,
SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr}
HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
Traffic Selector
Traffic Selector (IPv4 und IPv6)
Traffic Selector spezifiziert Protokoll, Portbereich und AdressbereichBeispiel: 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 TeilmengeTSi = 198.51.100.43, TSr = = 192.0.2.0 /24
Beispiel: Mit TSi = 198.51.100.0 /24, TSr = 0.0.0.0/0überlässt Initiator die Wahl des Remotenetzes komplett dem Responder
13.11.2018 17:01:51© M. Leischner Sicherheit in Netzen Folie 12
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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.
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 13
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
Austausch IKEv2 (IKE_INIT + IKE_AUTH)
13.11.2018 17:01:17
© M. Leischner Sicherheit in NetzenFolie 14
Initiator Responder
IKE-SA + CHILD_SA etabliert, Kommunikationspartner authent.
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}
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
IKEv2: CREATE_CHILD_SA
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 15
Initiator Responder
Ergebnis: neue CHILD_SA aufgebaut
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.
HDR,
SK {[N], SAi, Ni, [KEi,] TSi, TSr}
HDR,
SK {SAr, Nr, [KEr,] TSi, TSr}
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme 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:
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 16
Initiator Responder
Ergebnis: Rekeying durchgeführt
HDR, SK {N(REKEY_SA), SAi, Ni, [KEi,] TSi, TSr}
HDR, SK {SAr, Nr, [KEr,] TSi, TSr}
HochschuleBonn-Rhein-Sieg
Prof. Dr. Martin LeischnerNetzwerksysteme und TK
IPsec-Infrastruktur Netzlabor
13.11.2018 17:01:17© M. Leischner Sicherheit in Netzen Folie 17