IKEv1 mot IKEv2 med førehandsdelt nøkkel: kva som skil autentiseringa
Begge versjonane beviser kunnskap om den førehandsdelte nøkkelen utan å senda han, men gjev ulike inndata til ulike hashar. Samanlikn dei to spora.
To gatewayar sett opp med den same førehandsdelte nøkkelen fullfører ei handtrykkutveksling, og ein pakkefangst viser inga løyndom som går over linja. Det er den delen folk hugsar. Den interessante delen er kva kvar versjon faktisk reknar ut for å bevisa at løyndomen er kjend, fordi IKEv1 og IKEv2 byggjer beviset på ulike inndata og avdekkjer ulik informasjon medan dei gjer det. Les dei to spora side om side, og skilnaden sluttar å vera kosmetisk.
Kva beviset må oppnå
Diffie-Hellman gjev begge partane ein felles verdi der alle som ser på også kan rekna ut dei offentlege halvdelane. I seg sjølv beviser det ingenting om identitet: ein åtakar som fullfører ei nøkkelutveksling har same felles verdi som gatewayen din. Autentiseringstrinnet finst for å binda utvekslinga til ein løyndom som berre dei tiltenkte partane har, og til identitetane og parametrane dei vart samde om.
Den bindinga er grunnen til at hashen dekkjer meir enn nøkkelen. Dekkte han berre løyndomen, kunne ein åtakar spela han av i ei anna utveksling med andre identitetar eller forslag.
IKEv1 Main Mode: utleia SKEYID og prova han
Main Mode køyrer seks meldingar. Det første paret forhandlar tryggingsassosiasjonen, det andre utvekslar offentlege Diffie-Hellman-verdiar og nonce-verdiar, og det tredje ber identitetar pluss autentiseringshashar under krypteringa som nettopp vart etablert. RFC 2409 definerer konstruksjonen: med førehandsdelta nøkkel vert SKEYID utleia frå løyndomen og begge nonce-verdiane, og det seinare nøkkelmaterialet frå SKEYID, Diffie-Hellman-verdien, cookiane og konstantar.
Hashen i melding fem og seks vert rekna over Diffie-Hellman-verdien, dei to cookiane, forslaget og identiteten til avsendararen, med SKEYID som nøkkel. Mottakaren reknar han ut på nytt med sin eigen oppsette løyndom. Eit avvik avsluttar utvekslinga, og løyndomen er aldri ei nyttelast.
Aggressive Mode pressar same arbeidet ned i tre meldingar, noko som tyder at identitetar og autentiseringshash reiser før det finst ein kryptert kanal. Det er ei reell eksponering for ein gjetteleg løyndom, og det er skilt frå spørsmålet om løyndomen vart send. IKEv1 er avvikla av RFC 9395, så eit gammalt spor er ei diagnostisk øving og ikkje eit utrullingsmål.
IKEv2: ei anna utleiing og ei anna AUTH-nyttelast
IKEv2 brukar ikkje nøkkelskjemaet frå IKEv1 om att. Dei første IKE-nøklane kjem frå eit seed bygt av nonce-verdiane og Diffie-Hellman-verdien, og barnetryggingsassosiasjonane vert leia ut derifrå. Den førehandsdelte nøkkelen gjev ikkje seedet noko bidrag i det heile.
Autentiseringa dukkar då opp som ei AUTH-nyttelast. For nøkkelautentisering fastset RFC 7296 ein padda form av løyndomen, laga ved å hasha løyndomen med den faste strengen Key Pad for IKEv2, og deretter hasha dei signerte utvekslingsdataa og identiteten med den padda nøkkelen. Verifiseraren kan byggja same verdien på nytt; ein observatør kan ikkje, utan løyndomen.
Legg merke til kva som endra seg. I IKEv1 er løyndomen baka inn i nøkkelskjemaet før autentiseringshashen finst; i IKEv2 er nøkkelskjemaet uavhengig av løyndomen, og beviset er ei eiga nyttelast knytt til dei signerte oktettane. Same omgrepsmessige garanti, anna maskineri, og difor mappar parameternamn og fangstar ikkje ein til ein.
Kva ein observatør faktisk lærer
Offentlege Diffie-Hellman-verdiar, forslag, nonce-verdiar og cookiear er synlege i begge versjonar. Identitetar er synlege i IKEv1 Aggressive Mode og verna i dei andre tilfella. Løyndomen er aldri synleg.
Den siste setninga har ei grense som er verdt å nemna. Ein svak, menneskevald løyndom kan angripast med gjetting: åtakaren reknar ut kva autentiseringsverdien ville vera for ein kandidat og samanliknar. IKEv1 Aggressive Mode gjer dette billegast fordi beviset står i klartekst, og standardane åtvarar generelt mot løyndomar med låg entropi. Å aldri senda løyndomen er ikkje det same som å gjera ein dårleg løyndom trygg.
Kva du gjer med samanlikninga
Bruk éin unik løyndom per partspar, generer han frå ei tilfeldig kjelde og roter han gjennom den same provisjoneringsvegen som distribuerte han. Om løyndomen ligg i ein konfigurasjonsmal som vert send til kvar filial, er eit kompromiss på ein stad eit kompromiss overalt.
Føretrekk sertifikatbasert autentisering der driftskostnaden er akseptabel, sidan ho fjernar gjetterproblemet med den delte løyndomen og gjev kvar part ein eigen identitet. Der ein førehandsdelt nøkkel vert verande, hald han lang, avgrens omfanget og handsam IKE-versjonen som eit tryggleiksval, ikkje ein interoperabilitetsdetalj.