You are on page 1of 50

1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Het veld “volgende header” (“next header”; 8 bits) geeft aan welk type de
volgende header zal hebben.
Het veld “lengte payload” (“payload length”; 8 bits) geeft aan wat de omvang
is van de AH (in 32-bit-woorden min 2, minimum 2, max. 255, default 4).
Het SPI-veld (32 bits) identificeert een SA.
Het sequentiegetal (“sequence number”; 32 bits) is een monotoon
toenemende teller.
Het veld voor de authenticatiegegevens (“authentication data”) heeft een
variabele grootte (een geheel aantal woorden van 32 bits; default: 3) en
bevat de ICV (“Integrity Check Value”) of MAC voor dit pakket.
20
Bij initialisatie van SA: sequentiegetal op 0 gezet. Zender incrementeert
teller met 1 voor elk verzonden pakket (max. 2
32
–1 pakketten te versturen;
daarna nieuwe SA op te zetten). Binnen een SA heeft elk pakket een uniek
sequentiegetal.
IP is echter een “connectieloos” protocol, dat niet kan garanderen dat alle
pakketten aankomen, of dat pakketten in de juiste volgorde aankomen.
Daarom creëert de ontvanger een venster met grootte W (standaardwaarde:
64). Het meest rechtse getal in het venster is N, het hoogste sequentiegetal
van een ontvangen geldig pakket. Elk geldig pakket dat ontvangen wordt
met een sequentiegetal van N–W+1 tot N wordt aangestipt in het venster.
Werking:
•verifieer de authenticiteit van een inkomend pakket
•als het sequentiegetal van dit pakket binnen het venster valt, stip dit getal in
het venster aan (tenzij dit getal al aangestipt was: duplicatie van een
bestaand pakket)
•als pakket rechts is van venster, schuif venster naar rechts op zodat
sequentiegetal van nieuw pakket laatste element binnen venster wordt
•als pakket links van venster valt of authenticatie faalt, verwerp pakket
(auditeerbare gebeurtenis)
21
Bepaalde velden in een IP-header (zoals “Time To Live” of “Header
Checksum” in IPv4) kunnen veranderen tijdens het transport en worden
vervangen door nulbits voor de berekening van de HMAC. Voor veranderlijke
maar voorspelbare velden wordt de waarde bij aankomst aan het eindpunt
voor de AH-SA gebruikt. Ook de bits van de AH worden op nul gezet voor de
berekening van de ICV.
22
23
Bij transportmode wordt de AH ingevoegd in het IP-pakket. Het volledige
pakket is geauthentiseerd op de onvoorspelbaar veranderlijke velden na.
Bij tunnelmode wordt het oorspronkelijke pakket als het ware gebruikt als
payload voor een nieuw IP-pakket, met een nieuwe IP-header. Het volledige
pakket is geauthentiseerd op de onvoorspelbaar veranderlijke velden in de
nieuwe IP-header na (alle velden in het originele IP-pakket worden
geauthentiseerd).
24
25
Het veld voor de payload-gegevens heeft een veranderlijke grote (afhankelijk
van de doorgestuurde data). Om het ESP-pakket tot een geheel van
woorden van 32 bits, wordt er vulling voorzien. De vulling laat ook toe de te
versleutelen gegevens voor het symmetrisch encryptiealgoritme aan te
vullen tot het nodige veelvoud (van 64 bits voor DES of 3-DES, van 128 bits
voor AES). Waar een IV (“initialisation value”) nodig is voor het encryptie-
algoritme (CBC-mode bv.), wordt deze (onversleuteld, maar wel eventueel
voor authenticatie beveiligd door de ICV) geïntegreerd als eerste veld van de
payload data.
De veranderlijke hoeveelheid van de vulling laat een beperkte vorm van
vertrouwelijkheid van communicatie toe (de hoeveelheid werkelijk
uitgewisselde gegevens wordt gedeeltelijk verborgen gehouden).
Het veld voor de volgende header (“next header”) is een beschrijving van de
eerste header aanwezig in de payload (IPv6-header of header voor een
protocol uit een hogere laag).
De authenticatiegegevens zijn ook hier een exact veelvoud van 32 bits en
bevatten de ICV (zoals voor de AH). De authenticatie gebeurt over de
versleutelde gegevens.
26
27
De tunnelmode kan nuttig gebruikt worden als men een VPN wil creëren
tussen verschillende vestigingen van een bedrijf. Niet elk aangesloten
toestel hoeft te beschikken over IPsec-capaciteiten. Alleen een
beveiligingsgateway, die voor de verbinding van het (veilig geachte) lokale
netwerk met het internet zorgt, moet over IPsec-capaciteiten beschikken. In
dit geval zal het lokale verkeer zonder IPsec gebeuren, terwijl het uitgaande
verkeer (naar een andere vestiging) wel versleuteld zal worden door de
beveiligingsgateway. Op deze manier kunnen eventuele vertrouwelijke data
op veilige wijze via het internet verstuurd worden van de ene vestiging naar
de andere.
Deze configuratie geeft een zekere vertrouwelijkheid van de communicatie,
aangezien voor een aanvaller buiten één van de lokale netwerken alleen
zichtbaar is tussen welke lokale netwerken het verkeer gaat, maar niet
precies van welk werkstation naar welk werkstation.
In de praktijk zal de beveiligingsgateway ook een firewall bevatten om ook
andere beveiligingsfuncties te realiseren.
28
Bij transportmode wordt de ESP in het IP-pakket verwerkt. De ESP-trailer
(bevat de vulling en de velden voor de lengte van de vulling en voor de
volgende header). De originele IP-header is niet geauthentiseerd of
geëncrypteerd.
Bij tunnelmode wordt het oorspronkelijke pakket als het ware gebruikt als
payload voor een nieuw IP-pakket, met een nieuwe IP-header. Het volledige
oorspronkelijke pakket is versleuteld (en eventueel ook geauthentiseerd).

29
De 4 basiscombinaties moesten vroeger ondersteund worden door alle
IPsec-compatibele toestellen (is nu niet meer het geval voor RFC 4301).

30
Beveiliging tussen twee eindpunten. Mogelijke combinaties:
•AH in transportmode
•ESP in transportmode
•AH, gevolgd door ESP in transportmode (een ESP SA binnen een AH SA)
•één van de voorgaande binnen een AH of ESP in tunnelmode
31
Beveiliging aangeboden tussen gateways (routers, firewall,…). Geen IPsec-
implementatie op eindgebruikers. Basisondersteuning voor VPN. IPsec
specifieert dat een enkelvoudige tunnel (met AH, ESP of ESP met
authenticatie) in dit geval volstaat. Geneste tunnels zijn overbodig omdat de
IPsec-dienst op het volledige originele pakket slaat.
32
Uitbreiding van geval 2, waarbij ook beveiliging aangeboden wordt tussen de
eindpunten. De tunnel biedt authenticatie en/of vertrouwelijkheid voor
verkeer tussen intranets. Additionele IPsec-beveiliging kan door de
eindgebruikers worden toegevoegd voor het verkeer binnen de lokale
intranets.
33
Dit is het scenario voor een externe gebruiker (bv. telewerker) die het
internet gebruikt om toegang te krijgen tot de beveiligingsgateway van het
bedrijf (beveiligd door tunnel-SA) en daarna tot een server of werkstation
binnen het bedrijf (interne communicatie beveiligd door de interne SA’s).
34
35
De bedoeling van de cookies (pseudo-random-getal) is te vermijden dat een
aanvaller een groot aantal sleutels aanvraagt (die veel rekentijd vergen).
Door te eisen dat deze cookie teruggestuurd wordt in het eerste bericht van
de DH-dialoog, vermijdt men sleutelaanvragen die van een vervalst adres
komen.
Het gebruik van gelegenheidswoorden vermijdt replay-aanvallen.
De authenticatie van de DH-sleuteluitwisseling vermijdt de klassieke “man-
in-the-middle” aanval waarvoor gewone DH kwetsbaar is. Deze authenticatie
kan gebeuren op basis van digitale handtekeningen, asymmetrische
encryptie of zelfs symmetrische encryptie (met een sleutel die via een
andere weg afgeleid wordt).
36
37
38
39
De eerste respons kan gewijzigd worden als er een groot aantal halfopen
IKE-SA’s gedetecteerd wordt. Dan zal de responder een COOKIE-notificatie
versturen i.p.v. de DH-waarde KEr te berekenen. Dit moet DoS-aanvallen op
DH vermijden.
40
41
42
Een IKE-bericht bestaat uit een IKE-header gevolgd door 1 of meer
payloads.
De “initiator’s SPI” is de waarde die de initiator kiest om een unieke IKE SA
te identificeren (analoog voor Responder’s SPI).
Het veld voor de volgende payload (“Next Payload”) geeft aan welk het
eerste type payload is in dit bericht.
Daarna volgen 2 velden van 4 bits voor de gebruikte versie van IKE (“major
version”, “minor version”).
“Exchange type” geeft het type van uitwisseling aan. De vlaggen (“Flags”)
laten toe bepaalde opties te gebruiken in de IKE-uitwisseling.
Het bericht krijgt een unieke identificatie (“Message ID”, 32 bits).
Daarna volgt de lengte (“Length”) van het totale bericht (header en alle
payloads) in bytes (32 bits).
Elke payload begint met een generieke header voor payload. Voor de laatste
payload in een bericht zal het veld “Next Payload” (8 bits) de waarde nul
bevatten. Als de kritische bit (“C”) op 0 staat, mag de ontvanger van het
bericht de volgende payload overslaan als hij dit payloadtype niet
ondersteunt. Als de kritische bit de waarde 1 heeft en de ontvanger
ondersteunt het payloadtype niet, dan moet het volledige IKE-bericht
verworpen worden.
43
44
45
46
47
48
49
50