IKEv1 mod IKEv2: godkendelse med forud delt nøgle og hvad der er forskellen

To gateways konfigureret med den samme forud delte nøgle fuldfører et håndtryk, og en pakkefangst viser ingen hemmelighed, der krydser forbindelsen. Det er den del, folk husker. Den interessante del er, hvad hver version faktisk beregner for at bevise, at hemmeligheden er kendt, fordi IKEv1 og IKEv2 bygger dette bevis ud fra forskellige input og afslører forskellig information, mens de gør det. Læs de to spor side om side, og forskellen holder op med at være kosmetisk.

Hvad beviset skal opnå

Diffie-Hellman giver begge parter en fælles værdi, hvis offentlige halvdele enhver, der kigger med, også kan beregne. I sig selv beviser det intet om identitet: en angriber, der fuldfører en nøgleudveksling, har den samme fælles værdi som din gateway. Godkendelsestrinet findes for at binde den udveksling til en hemmelighed, som kun de tilsigtede parter har, og til de identiteter og parametre, de blev enige om.

Den binding er grunden til, at hashen dækker mere end nøglen. Hvis den kun dækkede hemmeligheden, kunne en angriber afspille den i en anden udveksling med andre identiteter eller forslag.

IKEv1 Main Mode: udled SKEYID, og bevis det derefter

Main Mode kører seks meddelelser. Det første par forhandler sikkerhedsassociationen, det andet udveksler Diffie-Hellman-offentlige værdier og nonces, og det tredje bærer identiteter plus godkendelses-hashes under den kryptering, der netop er etableret. RFC 2409 definerer konstruktionen: med godkendelse via forud delt nøgle udledes SKEYID af hemmeligheden og begge nonces, og det senere nøglemateriale udledes af SKEYID, den fælles Diffie-Hellman-værdi, cookies og konstanter.

Hashen i meddelelse fem og seks beregnes over Diffie-Hellman-værdien, de to cookies, forslaget og afsenderens identitet med SKEYID som nøgle. Modtageren genberegner den med sin egen konfigurerede hemmelighed. Uoverensstemmelse afslutter udvekslingen, og på intet tidspunkt er hemmeligheden selv en nyttelast.

Aggressive Mode komprimerer det samme arbejde til tre meddelelser, hvilket betyder, at identiteter og godkendelses-hashen rejser, før der findes en krypteret kanal. Det er en reel eksponering for en gættelig hemmelighed, og det er adskilt fra spørgsmålet om, hvorvidt hemmeligheden blev transmitteret. IKEv1 er forældet af RFC 9395, så et ældre spor er en diagnostisk øvelse snarere end et udrulningsmål.

IKEv2: en anden udledning og en anden AUTH-nyttelast

IKEv2 genbruger ikke IKEv1's nøgleplan. De indledende IKE-nøgler kommer fra et frø bygget af nonces og den fælles Diffie-Hellman-værdi, og underordnede sikkerhedsassociationer udledes derfra. Den forud delte nøgle fodrer slet ikke frøet.

Godkendelsen optræder derefter som en AUTH-nyttelast. Til godkendelse med delt nøgle specificerer RFC 7296 en udfyldt form af hemmeligheden, frembragt ved at hashe hemmeligheden med den faste streng Key Pad for IKEv2 og derefter hashe de signerede udvekslingsdata og identiteten med den udfyldte nøgle. Verifikatoren kan genskabe den samme værdi; en observatør kan ikke uden hemmeligheden.

Læg mærke til, hvad der ændrede sig. I IKEv1 er hemmeligheden bagt ind i nøgleplanen, før godkendelses-hashen findes; i IKEv2 er nøgleplanen uafhængig af hemmeligheden, og beviset er en særskilt nyttelast bundet til de signerede oketter. Samme konceptuelle garanti, andet maskineri, og derfor passer parameternavne og optagelser ikke en til en.

Hvad en observatør faktisk lærer

Diffie-Hellman-offentlige værdier, forslag, nonces og cookies er synlige i begge versioner. Identiteter er synlige i IKEv1 Aggressive Mode og beskyttet i de øvrige tilfælde. Hemmeligheden er aldrig synlig.

Den sidste sætning har en grænse, der er værd at nævne. En svag, menneskevalgt hemmelighed kan angribes ved at gætte: angriberen beregner, hvad godkendelsesværdien ville være for en kandidat-hemmelighed, og sammenligner. IKEv1 Aggressive Mode gør dette billigst, fordi beviset er i det fri, og standarderne advarer generelt om hemmeligheder med lav entropi. At aldrig transmittere hemmeligheden er ikke det samme som at gøre en dårlig hemmelighed sikker.

Hvad skal man gøre med sammenligningen

Brug én unik hemmelighed per partnerpar, generér den fra en tilfældig kilde, og roter den gennem den samme klargøringsvej, der distribuerede den. Hvis hemmeligheden ligger i en konfigurationsskabelon, der sendes til hver filial, er et kompromis ét sted et kompromis overalt.

Foretræk certifikatbaseret godkendelse, hvor driftsomkostningerne er acceptable, da det fjerner gætteproblemet med den delte hemmelighed og giver hver part en særskilt identitet. Hvor en forud delt nøgle bliver, skal den holdes lang, dens anvendelsesområde snævert, og IKE-versionen skal behandles som en sikkerhedsbeslutning snarere end en interoperabilitetsdetalje.