IKEv1 наспрам IKEv2 са унапред подељеним кључем: шта се разликује у аутентификацији

Два гејтвеја подешена са истим унапред подељеним кључем завршавају руковање, а снимак пакета не показује никакву тајну која прелази жицу. То је део који људи памте. Занимљив је део који свака верзија заиста израчунава да докаже да је тајна позната, јер IKEv1 и IKEv2 граде тај доказ из различитих улаза и притом откривају различите информације. Прочитајте два трага један уз други и разлика престаје да буде козметичка.

Шта доказ треба да постигне

Diffie-Hellman даје обема странама заједничку вредност чије јавне половине може да израчуна и свако ко посматра. Само по себи то ништа не доказује о идентитету: нападач који заврши размену кључева има исту заједничку вредност као ваш гејтвеј. Корак аутентификације постоји да ту размену веже за тајну коју имају само предвиђене стране, и за идентитете и параметре око којих су се договориле.

Управо та веза је разлог зашто хеш покрива више од кључа. Да покрива само тајну, нападач би могао да га репродукује у другој размени са другим идентитетима или предлозима.

IKEv1 Main Mode: извести SKEYID, затим га доказати

Main Mode извршава шест порука. Први пар преговара безбедносну асоцијацију, други размењује јавне Diffie-Hellman вредности и nonce, а трећи носи идентитете плус хешеве аутентификације под шифровањем које је управо успостављено. RFC 2409 дефинише конструкцију: уз аутентификацију унапред подељеним кључем, SKEYID се изводи из тајне и оба nonce, а каснији кључни материјал из SKEYID, заједничке Diffie-Hellman вредности, колачића и константи.

Хеш у петој и шестој поруци израчунава се над Diffie-Hellman вредношћу, два колачића, предлогом и идентитетом пошиљаоца, са SKEYID као кључем. Прималац га поново израчунава са својом подешеном тајном. Неслагање завршава размену, и тајна сама никада није терет.

Aggressive Mode сабија исти посао у три поруке, што значи да идентитети и хеш аутентификације путују пре него што постоји шифровани канал. То је стварна изложеност за тајну која се може погодити, и одвојено је од питања да ли је тајна пренета. IKEv1 је застарео према RFC 9395, па је стари траг дијагностичка вежба, а не циљ распоређивања.

IKEv2: другачије извођење и други AUTH терет

IKEv2 не користи поново распоред кључева из IKEv1. Почетни IKE кључеви долазе из семена изграђеног од nonce вредности и заједничке Diffie-Hellman вредности, а подређене безбедносне асоцијације изводе се из тога. Унапред подељени кључ уопште не храни семе.

Аутентификација се затим појављује као AUTH терет. За аутентификацију заједничким кључем RFC 7296 прописује попуњену форму тајне, добијену хеширањем тајне са фиксним низом Key Pad for IKEv2, а затим хеширањем потписаних података размене и идентитета тим попуњеним кључем. Проверавач може да обнови исту вредност; посматрач не може, без тајне.

Приметите шта се променило. У IKEv1 тајна је умешана у распоред кључева пре него што хеш аутентификације постоји; у IKEv2 распоред кључева је независан од тајне, а доказ је посебан терет везан за потписане октете. Иста концептуална гаранција, друга машинерија, и зато се имена параметара и снимци не поклапају један на један.

Шта посматрач заиста сазнаје

Јавне Diffie-Hellman вредности, предлози, nonce вредности и колачићи видљиви су у обе верзије. Идентитети су видљиви у IKEv1 Aggressive Mode и заштићени у осталим случајевима. Тајна никада није видљива.

Последња реченица има границу коју вреди изговорити. Слаба тајна коју је изабрао човек може се напасти погађањем: нападач израчуна каква би вредност аутентификације била за кандидат-тајну и упореди. IKEv1 Aggressive Mode то чини најјефтинијим јер је доказ отворен, а стандарди генерално упозоравају на тајне са ниском ентропијом. Никада не послати тајну није исто што и учинити лошу тајну безбедном.

Шта чинити са поређењем

Користите једну јединствену тајну по пару страна, генеришите је из случајног извора и мењајте је истим путем припреме који ју је дистрибуирао. Ако тајна стоји у шаблону конфигурације који иде у сваку филијалу, компромит на једном месту је компромит свуда.

Преферирајте аутентификацију засновану на сертификатима где је оперативни трошак прихватљив, јер уклања проблем погађања заједничке тајне и даје свакој страни посебан идентитет. Где унапред подељени кључ остаје, држите га дугим, ограничите опсег и третирајте верзију IKE као безбедносну одлуку, а не као детаљ интероперабилности.