IKEv1 teenoor IKEv2: verifikasie met voorafgedeelde sleutels en wat verskil

Twee poorte wat met dieselfde voorafgedeelde sleutel opgestel is, voltooi 'n handdruk, en 'n pakkettreking wys dat geen geheim oor die draad beweeg nie. Dit is die deel wat mense onthou. Die interessante deel is wat elke weergawe werklik bereken om te bewys dat die geheim bekend is, want IKEv1 en IKEv2 bou daardie bewys uit verskillende insette en openbaar verskillende inligting terwyl hulle dit doen. Lees die twee spore langs mekaar en die verskil hou op om kosmeties te wees.

Wat die bewys moet bereik

Diffie-Hellman gee albei eweknieë 'n gedeelde waarde waarvan enigiemand wat kyk ook die publieke helftes kan bereken. Op sigself bewys dit niks oor identiteit nie: 'n aanvaller wat 'n sleutelruiling voltooi, het dieselfde gedeelde waarde as jou poort. Die verifikasiestap bestaan om daardie ruiling te bind aan 'n geheim wat net die bedoelde eweknieë hou, en aan die identiteite en parameters waaroor hulle ooreengekom het.

Daardie binding is hoekom die hash meer as die sleutel dek. As dit net die geheim gedek het, kon 'n aanvaller dit in 'n ander ruiling met ander identiteite of voorstelle herspeel.

IKEv1 Main Mode: lei SKEYID af en bewys dit dan

Main Mode voer ses boodskappe uit. Die eerste paar onderhandel die sekuriteitsassosiasie, die tweede ruil Diffie-Hellman-publieke waardes en nonces uit, en die derde dra identiteite plus verifikasie-hashes onder die enkripsie wat pas gevestig is. RFC 2409 definieer die konstruksie: met verifikasie deur 'n voorafgedeelde sleutel word SKEYID uit die geheim en albei nonces afgelei, en die latere sleutelmateriaal word uit SKEYID, die Diffie-Hellman-gedeelde waarde, die koekies en konstantes afgelei.

Die hash in boodskappe vyf en ses word bereken oor die Diffie-Hellman-waarde, die twee koekies, die voorstel en die sender se identiteit, met SKEYID as sleutel. Die ontvanger herbereken dit met sy eie opgestelde geheim. 'n Wanpassing beëindig die ruiling, en op geen punt is die geheim self 'n loonvrag nie.

Aggressive Mode komprimeer dieselfde werk in drie boodskappe, wat beteken identiteite en die verifikasie-hash reis voordat 'n geënkripteerde kanaal bestaan. Dit is 'n werklike blootstelling vir 'n raaibare geheim, en dit is apart van die vraag of die geheim oorgedra is. IKEv1 word deur RFC 9395 afgeskaf, so 'n erfenisspoor is 'n diagnostiese oefening eerder as 'n ontplooiingsteiken.

IKEv2: 'n ander afleiding en 'n ander AUTH-loonvrag

IKEv2 hergebruik nie die IKEv1-sleutelprogram nie. Die aanvanklike IKE-sleutels kom uit 'n saad wat uit die nonces en die Diffie-Hellman-gedeelde waarde gebou is, en die kind-sekuriteitsassosiasies lei daaruit af. Die voorafgedeelde sleutel voed glad nie die saad nie.

Verifikasie verskyn dan as 'n AUTH-loonvrag. Vir verifikasie met 'n gedeelde sleutel spesifiseer RFC 7296 'n opgevulde vorm van die geheim, wat verkry word deur die geheim met die vaste string Key Pad for IKEv2 te hash, en dan die ondertekende ruilingsdata en die identiteit met daardie opgevulde sleutel te hash. Die verifieerder kan dieselfde waarde herbou; 'n waarnemer kan nie, sonder die geheim.

Let op wat verander het. In IKEv1 word die geheim in die sleutelprogram ingebak voordat die verifikasie-hash bestaan; in IKEv2 is die sleutelprogram onafhanklik van die geheim en is die bewys 'n afsonderlike loonvrag wat aan die ondertekende oktette gebind is. Dieselfde konseptuele waarborg, ander masjinerie, en daarom pas parameter name en opnames nie een-tot-een op mekaar nie.

Wat 'n waarnemer werklik leer

Diffie-Hellman-publieke waardes, voorstelle, nonces en koekies is in albei weergawes sigbaar. Identiteite is sigbaar in IKEv1 Aggressive Mode en beskerm in die ander gevalle. Die geheim is nooit sigbaar nie.

Daardie laaste sin het 'n beperking wat die moeite werd is om te noem. 'n Swak geheim wat deur 'n mens gekies is, kan deur raai aangeval word: die aanvaller bereken wat die verifikasiewaarde vir 'n kandidaatgeheim sou wees en vergelyk. IKEv1 Aggressive Mode maak dit die goedkoopste omdat die bewyse in die ope lug is, en die standaarde waarsku in die algemeen oor geheime met lae entropie. Om die geheim nooit oor te dra is nie dieselfde as om 'n slegte geheim veilig te maak nie.

Wat om met die vergelyking te doen

Gebruik een unieke geheim per ewekniepaar, genereer dit uit 'n ewekansige bron, en roteer dit deur dieselfde voorsieningspad wat dit versprei het. As die geheim in 'n konfigurasiesjabloon gestoor word wat na elke tak gestuur word, is 'n kompromie by een plek 'n kompromie oral.

Verkies sertifikaatgebaseerde verifikasie waar die bedryfskoste aanvaarbaar is, want dit verwyder die raaiprobleem van die gedeelde geheim en gee elke eweknie 'n eie identiteit. Waar 'n voorafgedeelde sleutel bly, hou dit lank, beperk die omvang daarvan en behandel die IKE-weergawe as 'n sekuriteitsbesluit eerder as 'n interoperabiliteitsdetail.