Cursus informatiebeveiliging Eric Laermans – Tom Dhaene IPsec Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Beveiliging op netwerklaag mogelijke indringer router router laptop modem server router router Appl Appl Transp Transp Netw Netw Netw Netw Netw Netw IPsec Data Data Data Data Data Data Data Fys Fys Fys Fys Fys Fys Fys draadloos Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beveiliging op netwerklaag Beveiliging op netwerkniveau voordelen applicatieonafhankelijk laat beveiliging toe ook voor applicaties die zelf geen beveiliging ondersteunen beveiligingsmechanismen beperkt tot enkele toegangspunten nadelen bericht onbeveiligd voorbij beveiligde toegangspunten bv. bij mailserver beveiligde opslag niet mogelijk Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: oorsprong IPsec (IP Security) beveiligingstoevoeging aan IP IP ongeschikt voor authenticatie: probleem van IP-spoofing geen vertrouwelijkheid in IP: probleem voor wachtwoorden toevoeging aan IPv4 geïntegreerd in IPv6 toekomstige standaard voor internetverkeer intussen derde versie IETF RFC 4301 tot 4304, 4307 tot 4309, 4835, 5996 zie ook boek H. 19, p. 639vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: aspecten 3 aspecten in IPsec vertrouwelijkheidsfunctie authenticatiefunctie en gedeeltelijk data-integriteit sleutelbeheer voor veilige uitwisseling van geheime sleutels Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: toepassingen Toepassingen VPN (virtual private network) voor een bedrijf: beveiligde communicatie mogelijk over publieke netwerken tussen geografisch verspreide vestigingen van bedrijf beveiliging aan “gateways” (toegangspoorten) alsof deelnetwerken niet via publiek netwerk, maar via gewone LAN (ontoegankelijk voor buitenwereld) verbonden waren beveiligde toegang tot LAN via internet ook vaak als VPN beschouwd … Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: typisch scenario gebruiker met IPsec publiek netwerk IP-hdr IPsec -hdr beveiligde data IP-hdr IPsec -hdr beveiligde data IP-hdr IPsec -hdr beveiligde data IP-hdr data IPsec gateway IP-hdr data Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: voordelen Voordelen bij implementatie op firewall of router sterke beveiliging voor alle verkeer dat perimeter kruist, maar geen belasting op intern bedrijfsverkeer transparant voor applicatielaag kan transparant zijn voor eindgebruikers eindgebruiker hoeft zich geen (of weinig) zorgen te maken over beveiligingsfuncties beveiliging van individuele gebruikers mogelijk geschikt voor afstandswerkers Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: nadelen Nadelen gebruik van systeemmiddelen rekentijd nodig voor cryptografische functies complexiteit van specificatie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Toepassingen voor routering IPsec en routering Toepassingen voor routering authenticatie van routeringsberichten aankondigingen updates … zonder IPsec kan vervalste routeringsinformatie verstuurd worden Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beschikbare protocols IPsec: diensten Beschikbare protocols AH (“Authentication Header”) authenticatie ondersteuning optioneel in recente IPsec-implementaties ESP (“Encapsulating Security Payload”) vertrouwelijkheid Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: beveiligingsfuncties Realiseerbare beveiligingsfuncties toegangscontrole connectieloze integriteit authenticatie van oorsprong van gegevens afweren van “replay”-aanvallen vertrouwelijkheid beperkte vertrouwelijkheid van communicatie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: beveiligingsassociaties Beveiligingsassociaties (“security associations” of SA) eenrichtingsrelatie tussen afzender en ontvanger verschaft beveiligingsdiensten aan vervoerd verkeer twee associaties nodig voor bidirectioneel verkeer geïdentificeerd door SPI (“Security Parameters Index”) bitstring voor lokaal gebruik, aanwezig in AH- of ESP-header (om juiste SA te kunnen selecteren) IP bestemmingsadres (eindgebruiker, firewall, router,…) identificatie van het beveiligingsprotocol (AH of ESP) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: SA-parameters SA-parameters in elke implementatie van IPsec: SA-databank met parameters geassocieerd met elke SA bevat (o.a.) volgende parameters teller voor sequentiegetal (sequence number counter) 32 bits; gebruikt om sequentiegetal te genereren in AH- of ESP-headers anti-replay venster opvangen of inkomend pakket (AH of ESP) replay is Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: SA-parameters SA-parameters met o.a. volgende parameters AH-informatie nodige parameters voor AH (authenticatiealgoritme, sleutels, levensduur sleutels,…) ESP-informatie nodige informatie voor ESP (authenticatie- en encryptiealgoritme, sleutels, initiële waarden,…) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: SA-parameters SA-parameters met o.a. volgende parameters geldigheidsduur (lifetime) van SA tijdsinterval of aantal bytes, waarna SA vervangen of beëindigd moet worden protocolmode voor IPsec tunnel-, transport- of wildcardmode Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Security Policy Database (SPD) IPsec: SPD Security Policy Database (SPD) analyseert uitgaand IP-verkeer op basis van geschikte velden in IP-pakket IP-adres bestemming, gebruikersID,… selecteert SA voor geanalyseerd pakket en geassocieerde SPI eventueel geen SA voor toegelaten niet-IPsec-verkeer voert de vereiste IPsec-verwerking uit AH of ESP zie ook boek H. 19.2 p. 648-649 Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Authentication Header (AH) IPsec: AH Authentication Header (AH) ondersteunt data-integriteit en authenticatie van IP-pakketten laat router/werkstation toe gebruiker of applicatie te authentiseren vermijdt IP-spoofing bevat mechanisme tegen replay authenticatie op basis van MAC vereist gedeelde geheime sleutel Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Authenticatiegegevens IPsec: AH 8 bits 8 bits 16 bits volgende header lengte payload voorbehouden SPI sequentiegetal Authenticatiegegevens 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. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

pakket nog niet ontvangen IPsec: AH en ESP IPsec: anti-replay-mechanisme vermijden van gedupliceerde authentieke pakketten via sequentiegetal verschuivend venster laatst ontvangen pakket pakket ontvangen N–W N … … … Bij initialisatie van SA: sequentiegetal op 0 gezet. Zender incrementeert teller met 1 voor elk verzonden pakket (max. 232–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) venster pakket nog niet ontvangen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

AH: Integrity Check Value (ICV) IPsec: AH AH: Integrity Check Value (ICV) berekening van MAC gebruikt doorgaans HMAC met SHA-1 zie ook boek H. 12.5 p. 399vv. beperkt tot 96 eerste bits berekend over onveranderlijke of voorspelbare velden van IP-header AH (buiten veld voor authenticatiegegevens) IP-payload optioneel kunnen ook andere MAC’s ondersteund worden dan de verplicht te ondersteunen protocols: HMAC-SHA-1-96 AES-XCBC-MAC-96 dit laatste niet helemaal verplicht (SHOULD+) 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. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: AH – transport- en tunnelmode server transport mode lokaal netwerk publiek netwerk transport mode IPsec-gateway tunnel mode Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: AH – transport- en tunnelmode orig. IP-hdr IP-payload IPv4-pakket orig. IP-hdr AH IP-payload IPv4: AH Transport nwe. IP-hdr AH orig. IP-hdr IP-payload IPv4: AH Tunnel IPv6-pakket orig. IP-hdr ext. hdrs IP-payload IPv6: AH Transport orig. IP-hdr ext. hdrs1 AH ext. hdrs2 IP-payload 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). IPv6: AH Tunnel nwe. IP-hdr ext. hdrs AH orig. IP-hdr ext. hdrs IP-payload Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Encapsulating Security Payload (ESP) IPsec: ESP Encapsulating Security Payload (ESP) realiseert vertrouwelijkheidsfunctie en in beperkte mate vertrouwelijkheid van communicatie maakt gebruik van traditionele encryptiealgoritmen 3-DES (MUST-) AES-128-CBC (SHOULD+), AES-CTR (SHOULD) DES intussen sterk afgeraden (SHOULD NOT) realiseert authenticatie (optioneel) zelfde principe als voor AH HMAC-SHA-1-96 (MUST) AES-XCBC-MAC-96 (SHOULD+) (of optioneel ook andere MAC-protocols) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: ESP SPI sequentiegetal gegevens payload vulling (0-255 bytes) 8 bits 8 bits 16 bits SPI sequentiegetal gegevens payload vulling (0-255 bytes) lengte vulling volgende header Authenticatiegegevens 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. geëncrypteerde gegevens geauthentiseerde gegevens Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: ESP – transportmode van eindpunt tot eindpunt: encryptie (en eventueel authenticatie) geen vertrouwelijkheid van communicatie bv. voor teleworking versleuteld IP-verkeer tussen eindpunten lokaal netwerk internet Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: ESP – tunnelmode versleutelde tunnels met IP-verkeer lokaal netwerk lokaal netwerk internet lokaal netwerk lokaal netwerk 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. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: ESP – transport- en tunnelmode orig. IP-hdr IP-payload IPv4-pakket orig. IP-hdr ESP hdr IP-payload ESP trlr ESP auth IPv4: ESP Transport nwe. IP-hdr ESP hdr orig. IP-hdr IP-payload ESP trlr ESP auth IPv4: ESP Tunnel orig. IP-hdr ext. hdrs IP-payload IPv6-pakket orig. IP-hdr ext. hdrs1 ESP hdr ext. hdrs2 IP-payload ESP trlr ESP auth IPv6: ESP Transport 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). IPv6: ESP Tunnel nwe. IP-hdr ext. hdrs ESP hdr orig. IP-hdr ext. hdrs IP-payload ESP trlr ESP auth geëncrypteerde gegevens geauthentiseerde gegevens Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: combineren van SA’s Bundelen van SA’s evidente bundel: AH + ESP voor zelfde IP-stroom zelfde eindpunten één enkel niveau van combinatie mogelijk “transport adjacency” combineren van tunnels niet noodzakelijk zelfde eindpunten voor elke tunnel verscheidene niveaus mogelijk “iterated tunneling” combinaties van beide benaderingen 4 basiscombinaties gedefinieerd in IPsec in vorige versie De 4 basiscombinaties moesten vroeger ondersteund worden door alle IPsec-compatibele toestellen (is nu niet meer het geval voor RFC 4301). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: combineren van SA’s – geval 1 1 of meer SA’s toestel met IPsec-implementatie 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 lokaal intranet internet lokaal intranet Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: combineren van SA’s – geval 2 tunnel-SA beveiligingsgateway intranet toestel met IPsec-implementatie 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. lokaal intranet internet lokaal intranet Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: combineren van SA’s – geval 3 tunnel-SA 1 of 2 SA’s toestel met IPsec-implementatie lokaal intranet internet lokaal intranet 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. beveiligingsgateway intranet Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: combineren van SA’s – geval 4 tunnel-SA 1 of 2 SA’s toestel met IPsec-implementatie internet lokaal intranet 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). beveiligingsgateway intranet Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer Sleutelbeheer sleutelgeneratie + sleutelverdeling typisch 2 paar sleutels nodig 2 per richting voor AH en ESP manueel sleutelbeheer systeembeheerder configureert manueel elk deelsysteem automatisch sleutelbeheer geautomatiseerd systeem voor aanmaak van sleutels op aanvraag voor SA’s in grote systemen via IKEv2 (Internet Key Exchange) laatste versie uit 2010 IETF RFC 5996 138 blz. specificatie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleutelgeneratie en sleuteluitwisseling IPsec: sleutelbeheer Sleutelgeneratie en sleuteluitwisseling vóór IKEv2: Oakley (RFC 2412) + ISAKMP (RFC 2408) steunt op (efemere) Diffie-Hellman-algoritme, met extra beveiligingselementen uitwisseling van cookies groepen (globale parameters voor DH) gelegenheidswoorden (“nonces”) DH-sleuteluitwisseling met authenticatie zie ook boek H. 19.5, p. 662vv. 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). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleutelgeneratie en sleuteluitwisseling IPsec: sleutelbeheer Sleutelgeneratie en sleuteluitwisseling uitwisseling van cookies afhankelijk van specifieke communicerende partijen hoeft niet opgeslagen te worden, maar wel verifieerbaar door uitgevende partij (m.b.v. lokaal gegenereerde geheime waarde) snel te genereren en te verifiëren aanbevolen implementatie: hashwaarde van IP-bron- en bestemmingsadres, UDP-bron- en bestemmingspoort en een lokaal gegenereerde geheime waarde Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleutelgeneratie en sleuteluitwisseling IPsec: sleutelbeheer Sleutelgeneratie en sleuteluitwisseling groepen keuze van algebraïsche groep waarover DH uitgevoerd wordt modulomachtsverheffing met 768 of 1024 bits (klassieke DH) (RFC 2412) specificatie van priemgetallen en generator vermenigvuldiging over elliptische krommen (RFC 3526) specificatie van parameters van kromme en generator Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleutelgeneratie en sleuteluitwisseling IPsec: sleutelbeheer Sleutelgeneratie en sleuteluitwisseling authenticatiemechanisme digitale handtekening (over de essentiële delen) asymmetrische encryptie met vertrouwelijke seleutel symmetrische encryptie met een sleutel afgeleid via een “out-of-band”-kanaal Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer Sleuteluitwisseling “Initial exchanges” (I: initiator; R: responder) I → R: HDR, SAi1, KEi, Ni HDR: IKE-header (met SPI’s e.d.) SAi1: cryptografische algoritmen ondersteund door I voor IKE SA KEi: DH-waarde voor I Ni: nonce voor I R → I: HDR, SAr1, KEr, Nr, [CERTREQ] SAr1: gekozen cryptografische suite [CERTREQ]: optionele “certificate request” uit deze twee eerste stappen af te leiden: sleutels SK_e en SK_a voor encryptie/MAC voor elk van beide richtingen sleutel SK_d voor verder sleutelmateriaal 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. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer Sleuteluitwisseling “Initial exchanges”: vervolg I → R: HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} SK{…}: encryptie + authenticatie met intussen afgeleide sleutels SK_e en SK_a IDi: identiteit van I [CERT]: optionele certificaten AUTH: IKE payload voor authenticatie SAi2: cryptografische algoritmen ondersteund door I voor IPsec SA TSi: Traffic Selector voor IPsec-SA (info voor SPD) R → I: HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} hierna is een eerste paar “Child SA’s” aangemaakt voor normale IPsec-communicatie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling en beheer IPsec: sleutelbeheer Sleuteluitwisseling en beheer nieuwe SA’s kunnen aangemaakt worden via “CREATE_CHILD_SA” exchanges voor het verdere beheer van de communicatie kunnen informationele uitwisselingen gebruikt worden zie ook boek H. 19.5, p. 666-667 Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer – IKEv2 8 bits 8 bits 16 bits Initiator’s SPI 2 woorden Responder’s SPI 2 woorden Next Payload Maj. V. Min. V. Exchange type Flags Message ID Length IKE header 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. Next Payload C RESERVED Payload Length generieke header voor payload Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer – IKEv2 Enkele payload-types voor IKE-berichten Security Association (SA) beginnen met opzetten van nieuwe SA bevat info over te gebruiken beveiligingsmechanismen Key Exchange (KE) info over sleuteluitwisselingstechniek Identification (ID) typisch een IP-adres Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

IPsec: sleutelbeheer – IKEv2 Enkele payload-types voor IKE-berichten Authentication (AUTH) gebruikte techniek (RSA, DSS,…) authenticatiedata … zie ook boek H. 19.5, p. 668vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

VPN's Basisprincipe van VPN VPN = beveiligde tunnel van site tot site niet louter beveiligde remote login VPN-box site A VPN-box site B internet host site A host site B beveiligde tunnel Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Problemen met traditionele IPsec-VPN VPN's Problemen met traditionele IPsec-VPN complexiteit van IPsec vooral de sleuteluitwisseling interoperabiliteitsproblemen tussen verschillende (partiële) implementaties van de norm problemen met NAT en (niet-IPsec) firewalls voor AH eenvoudigere alternatieven zijn welkom Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Alternatieven voor IPsec VPN's Alternatieven voor IPsec “SSL” OpenVPN TLS/SSL voor sessie-authenticatie ESP IPsec-achtig voor tunnelbeveiliging SSH OpenSSH beide bieden beveiligde tunnels hoofdverschil met IPsec beveiliging bovenop transportlaag i.p.v. beveiliging op netwerklaag Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

VPN's IPsec (ESP) tunnel origineel IP-pakket gebruikt als payload voor nieuw (beveiligd) IP-pakket, met nieuwe IP-header een enkele TCP-connectie omvat in originele IP-payload orig. IPhdr IP payload origineel IPv4-pakket nwe. IPhdr ESP hdr orig. IPhdr IP payload ESP trlr ESP auth IPv4: ESP-Tunnel Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

VPN's SSL- of SSH-VPN laag-2/3-tunnel VPN origineel dataframe/IP-pakket wordt payload van (beveiligde) connectie tussen VPN-boxes inclusief TCP/UDP-headers interne TCP/UDP-connectie nieuwe TCP/UDP-connectie tussen VPN-boxes externe TCP/UDP-connectie orig. MAC orig. IP orig. TCP TCP payload origineel dataframe SSL/ SSH nwe. MAC nwe. IP nwe. TCP orig. MAC orig. IP orig. TCP TCP payload VPN tunnel frame Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Mogelijke problemen met SSL- of SSH-VPN VPN's Mogelijke problemen met SSL- of SSH-VPN mogelijke problemen bij tunnelen van TCP over TCP alleen als eigenschappen link tussen VPN-boxes slecht geen probleem bij tunnelen van TCP over UDP (OpenVPN) of UDP over TCP (SSH) pakketinspectie hogerop in protocolstack meer verwerking vooraleer ongeldig pakket gedetecteerd wordt hoger risico op DoS niet-standaard maar dit geldt ook voor meeste IPsec-oplossingen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans