IKEv1 laban sa IKEv2 na may pre-shared key: ano ang kaibahan sa pagpapatotoo

Dalawang gateway na naka-configure sa parehong pre-shared key ang nagtatapos ng handshake, at ang packet capture ay walang ipinapakitang lihim na tumatawid sa kable. Iyon ang bahaging natatandaan ng mga tao. Ang kawili-wiling bahagi ay kung ano talaga ang kinukuwenta ng bawat bersyon para patunayang kilala ang lihim, dahil ang IKEv1 at IKEv2 ay bumubuo ng patunay na iyon mula sa magkaibang input at naglalantad ng magkaibang impormasyon habang ginagawa ito. Basahin ang dalawang trace nang magkatabi at tumitigil ang pagkakaiba sa pagiging kosmetiko.

Ano ang dapat makamit ng patunay

Binibigyan ng Diffie-Hellman ang dalawang panig ng isang shared value na ang publikong kalahati ay makukuwenta rin ng sinumang nanonood. Sa sarili nito ay wala itong pinatutunayan tungkol sa pagkakakilanlan: ang umaatake na nakatapos ng key exchange ay may parehong shared value ng iyong gateway. Ang hakbang ng pagpapatotoo ay naroon para igapos ang exchange na iyon sa isang lihim na hawak lamang ng nilalayong panig, at sa mga pagkakakilanlan at parametrong napagkasunduan nila.

Ang pagkakagapos na iyon ang dahilan kung bakit ang hash ay sumasaklaw nang higit sa key. Kung ang lihim lamang ang saklaw nito, maaaring i-replay ito ng umaatake sa ibang exchange na may ibang pagkakakilanlan o proposal.

IKEv1 Main Mode: kunin ang SKEYID, pagkatapos patunayan

Anim na mensahe ang pinapatakbo ng Main Mode. Ang unang pares ay nakikipagnegosasyon sa security association, ang pangalawa ay nagpapalitan ng publikong Diffie-Hellman value at nonce, at ang pangatlo ay nagdadala ng pagkakakilanlan at authentication hash sa ilalim ng encryption na kauupo lang itinatag. Tinutukoy ng RFC 2409 ang konstruksyon: sa pagpapatotoo na pre-shared key, ang SKEYID ay hinango mula sa lihim at sa dalawang nonce, at ang susunod na keying material mula sa SKEYID, shared value ng Diffie-Hellman, mga cookie at constant.

Ang hash sa ikalima at ikaanim na mensahe ay kinukuwenta sa Diffie-Hellman value, dalawang cookie, proposal at pagkakakilanlan ng nagpadala, gamit ang SKEYID bilang key. Kinukuwenta itong muli ng tumatanggap gamit ang sarili nitong naka-configure na lihim. Ang hindi pagtutugma ay nagtatapos sa exchange, at ang lihim mismo ay hindi kailanman naging payload.

Pinipiga ng Aggressive Mode ang parehong gawain sa tatlong mensahe, ibig sabihin ay naglalakbay ang pagkakakilanlan at authentication hash bago pa may encrypted channel. Tunay na pagkakalantad ito para sa nahuhulaang lihim, at hiwalay ito sa tanong kung naipadala ang lihim. Lipas na ang IKEv1 ayon sa RFC 9395, kaya ang lumang trace ay diagnostic na ehersisyo, hindi target ng deployment.

IKEv2: ibang derivation at ibang AUTH payload

Hindi ginagamit muli ng IKEv2 ang key schedule ng IKEv1. Ang mga paunang IKE key ay nagmumula sa seed na binuo mula sa nonce at shared value ng Diffie-Hellman, at ang mga child security association ay hinango doon. Ang pre-shared key ay hindi pumapasok sa seed.

Lumilitaw nga ang pagpapatotoo bilang AUTH payload. Para sa shared-key authentication, tinutukoy ng RFC 7296 ang padded na anyo ng lihim, na nakukuha sa pag-hash ng lihim gamit ang fixed string Key Pad for IKEv2, at pagkatapos ay pag-hash sa nilagdaang exchange data at pagkakakilanlan gamit ang padded key na iyon. Kayang buuin muli ng verifier ang parehong value; hindi kaya ng observer, kung wala ang lihim.

Pansinin kung ano ang nagbago. Sa IKEv1 ang lihim ay inihurno sa key schedule bago pa umiral ang authentication hash; sa IKEv2 ang key schedule ay malaya sa lihim at ang patunay ay hiwalay na payload na nakatali sa nilagdaang octet. Pareho ang konseptwal na garantiya, iba ang makinarya, at iyon ang dahilan kung bakit hindi nagmamapa nang isa-sa-isa ang mga pangalan ng parameter at ang mga capture.

Ano ang talagang nalalaman ng observer

Nakikita sa dalawang bersyon ang publikong Diffie-Hellman value, proposal, nonce at cookie. Nakikita ang pagkakakilanlan sa IKEv1 Aggressive Mode at protektado sa ibang pagkakataon. Hindi kailanman nakikita ang lihim.

May hangganan ang huling pangungusap na dapat sabihin. Ang mahinang lihim na pinili ng tao ay maaaring atakihin sa pamamagitan ng paghula: kinukuwenta ng umaatake kung ano ang magiging authentication value para sa kandidatong lihim at inihahambing. Ginagawa itong pinakamura ng IKEv1 Aggressive Mode dahil nakalantad ang ebidensya, at nagbabala ang mga pamantayan tungkol sa mababang-entropy na lihim sa pangkalahatan. Ang hindi kailanman pagpapadala ng lihim ay hindi katulad ng paggawa ng masamang lihim na ligtas.

Ano ang gagawin sa paghahambing

Gumamit ng isang natatanging lihim sa bawat pares ng peer, likhain ito mula sa random na pinagmulan, at paikutin ito sa parehong daan ng provisioning na nagpamahagi nito. Kung ang lihim ay nasa template ng configuration na ipinapadala sa bawat sangay, ang kompromiso sa isang lugar ay kompromiso sa lahat.

Mas mainam ang pagpapatotoo na nakabatay sa sertipiko kung katanggap-tanggap ang gastos sa operasyon, dahil inaalis nito ang problema sa paghula sa shared secret at binibigyan ang bawat peer ng natatanging pagkakakilanlan. Kung mananatili ang pre-shared key, panatilihing mahaba ito, limitahan ang saklaw at ituring ang bersyon ng IKE bilang desisyon sa seguridad, hindi detalye ng interoperabilidad.