IKEv1 lawan IKEv2 dengan kunci pra-kongsi: apa yang berbeza pada pengesahan

Dua get laluan yang dikonfigurasi dengan kunci pra-kongsi yang sama menyelesaikan handshake, dan rakaman paket tidak menunjukkan sebarang rahsia melintasi wayar. Itulah bahagian yang orang ingat. Bahagian yang menarik ialah apa yang sebenarnya dikira oleh setiap versi untuk membuktikan rahsia itu diketahui, kerana IKEv1 dan IKEv2 membina bukti itu daripada input berbeza dan mendedahkan maklumat berbeza semasa melakukannya. Baca kedua-dua jejak bersebelahan dan perbezaannya berhenti bersifat kosmetik.

Apa yang perlu dicapai oleh bukti

Diffie-Hellman memberi kedua-dua pihak satu nilai kongsi yang bahagian awamnya juga boleh dikira oleh sesiapa yang memerhati. Dengan sendirinya itu tidak membuktikan apa-apa tentang identiti: penyerang yang menyelesaikan pertukaran kunci mempunyai nilai kongsi yang sama dengan get laluan anda. Langkah pengesahan wujud untuk mengikat pertukaran itu kepada rahsia yang hanya dipegang oleh pihak yang dimaksudkan, dan kepada identiti serta parameter yang mereka persetujui.

Ikatan itulah sebabnya hash meliputi lebih daripada kunci. Jika ia hanya meliputi rahsia, penyerang boleh memainkannya semula ke pertukaran lain dengan identiti atau cadangan berbeza.

IKEv1 Main Mode: terbitkan SKEYID, kemudian buktikannya

Main Mode menjalankan enam mesej. Pasangan pertama merundingkan persatuan keselamatan, pasangan kedua bertukar nilai awam Diffie-Hellman dan nonce, dan yang ketiga membawa identiti serta hash pengesahan di bawah penyulitan yang baru sahaja dibentuk. RFC 2409 mentakrifkan pembinaannya: dengan pengesahan kunci pra-kongsi, SKEYID diterbitkan daripada rahsia dan kedua-dua nonce, dan bahan kunci seterusnya daripada SKEYID, nilai kongsi Diffie-Hellman, kuki dan pemalar.

Hash dalam mesej kelima dan keenam dikira atas nilai Diffie-Hellman, dua kuki, cadangan dan identiti penghantar, dengan SKEYID sebagai kunci. Penerima mengiranya semula dengan rahsia yang dikonfigurasi padanya. Ketidakpadanan menamatkan pertukaran, dan rahsia itu sendiri tidak pernah menjadi muatan.

Aggressive Mode memadatkan kerja yang sama ke dalam tiga mesej, bermakna identiti dan hash pengesahan bergerak sebelum saluran tersulit wujud. Itu pendedahan sebenar untuk rahsia yang boleh diteka, dan ia berasingan daripada persoalan sama ada rahsia itu dihantar. IKEv1 telah lapuk oleh RFC 9395, jadi jejak lama ialah latihan diagnostik, bukan sasaran penggunaan.

IKEv2: terbitan berbeza dan muatan AUTH berbeza

IKEv2 tidak menggunakan semula jadual kunci IKEv1. Kunci IKE awal datang daripada benih yang dibina daripada nonce dan nilai kongsi Diffie-Hellman, dan persatuan keselamatan anak diterbitkan daripadanya. Kunci pra-kongsi sama sekali tidak menyumbang kepada benih.

Pengesahan kemudian muncul sebagai muatan AUTH. Untuk pengesahan kunci kongsi, RFC 7296 menetapkan bentuk rahsia yang berlapik, diperoleh dengan menghash rahsia dengan rentetan tetap Key Pad for IKEv2, dan kemudian menghash data pertukaran yang ditandatangani dan identiti dengan kunci berlapik itu. Pengesah boleh membina semula nilai yang sama; pemerhati tidak boleh, tanpa rahsia.

Perhatikan apa yang berubah. Dalam IKEv1 rahsia dibakar ke dalam jadual kunci sebelum hash pengesahan wujud; dalam IKEv2 jadual kunci bebas daripada rahsia dan buktinya ialah muatan berasingan yang terikat pada oktet yang ditandatangani. Jaminan konsep yang sama, jentera berbeza, dan sebab itulah nama parameter dan rakaman tidak memetakan satu lawan satu.

Apa yang sebenarnya dipelajari oleh pemerhati

Nilai awam Diffie-Hellman, cadangan, nonce dan kuki kelihatan dalam kedua-dua versi. Identiti kelihatan dalam IKEv1 Aggressive Mode dan dilindungi dalam kes lain. Rahsia tidak pernah kelihatan.

Ayat terakhir itu mempunyai had yang wajar dinyatakan. Rahsia lemah yang dipilih manusia boleh diserang dengan meneka: penyerang mengira apakah nilai pengesahan bagi calon rahsia dan membandingkannya. IKEv1 Aggressive Mode menjadikan ini paling murah kerana buktinya terang-terang, dan piawaian memberi amaran tentang rahsia berentropi rendah secara umum. Tidak pernah menghantar rahsia bukanlah sama dengan menjadikan rahsia buruk selamat.

Apa yang perlu dibuat dengan perbandingan ini

Gunakan satu rahsia unik bagi setiap pasangan rakan, jana daripada sumber rawak, dan putarkannya melalui laluan peruntukan yang sama yang mengagihkannya. Jika rahsia disimpan dalam templat konfigurasi yang dihantar ke setiap cawangan, kompromi di satu tempat ialah kompromi di semua tempat.

Utamakan pengesahan berasaskan sijil di mana kos operasi boleh diterima, kerana ia menghapuskan masalah meneka rahsia kongsi dan memberi setiap rakan identiti yang berbeza. Di mana kunci pra-kongsi kekal, pastikan ia panjang, sempit skopnya, dan anggap versi IKE sebagai keputusan keselamatan, bukan butiran interoperabiliti.