Modul 4: IPSEC Teil 2 IKEv2 - leischner.inf.h-brs.de · Modul 4: IPSEC Teil 2 ... Payload (ESP) RFC 4303 (12/05) Cryptographic Algorithm RFC 7321 (08/14) Internet Key Exchange (IKEv2)

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)



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)



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



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




IKEv1-Terminologie Create_Child_SA Exchange

Initial_Exchange

Übersicht Ablauf von IKEv2


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



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



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




IKEv2: IKE_INIT


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]



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




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




IKEv2: IKE_AUTH


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}



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




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.




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}



IKEv2: CREATE_CHILD_SA


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


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


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



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

Ergebnis: Rekeying durchgeführt

HDR, SK {N(REKEY_SA), SAi, Ni, [KEi,] TSi, TSr}

HDR, SK {SAr, Nr, [KEr,] TSi, TSr}



IPsec-Infrastruktur Netzlabor


Documents

Modul 4: IPSEC Teil 2 IKEv2 - leischner.inf.h-brs.de · Modul 4: IPSEC Teil 2 ... Payload (ESP) RFC 4303 (12/05) Cryptographic Algorithm RFC 7321 (08/14) Internet Key Exchange (IKEv2)