IKEv1 dan IKEv2 dengan kunci pra-bagi: apa yang berbeda pada autentikasi

Dua gateway yang dikonfigurasi dengan kunci pra-bagi yang sama menyelesaikan handshake, dan rekaman paket tidak menunjukkan rahasia apa pun yang melintasi kabel. Itulah bagian yang orang ingat. Bagian yang menarik adalah apa yang sebenarnya dihitung tiap versi untuk membuktikan bahwa rahasia itu diketahui, karena IKEv1 dan IKEv2 menyusun bukti itu dari masukan berbeda dan menyingkap informasi berbeda saat melakukannya. Baca kedua jejak berdampingan dan perbedaannya berhenti bersifat kosmetik.

Apa yang harus dicapai bukti

Diffie-Hellman memberi kedua pihak nilai bersama yang bagian publiknya juga dapat dihitung siapa pun yang mengamati. Dengan sendirinya itu tidak membuktikan apa pun tentang identitas: penyerang yang menyelesaikan pertukaran kunci memiliki nilai bersama yang sama dengan gateway Anda. Langkah autentikasi ada untuk mengikat pertukaran itu pada rahasia yang hanya dipegang pihak yang dimaksud, dan pada identitas serta parameter yang mereka sepakati.

Ikatan itulah sebabnya hash mencakup lebih dari sekadar kunci. Jika hanya mencakup rahasia, penyerang dapat memutarnya ulang ke pertukaran lain dengan identitas atau proposal berbeda.

IKEv1 Main Mode: turunkan SKEYID, lalu buktikan

Main Mode menjalankan enam pesan. Pasangan pertama menegosiasikan asosiasi keamanan, pasangan kedua bertukar nilai publik Diffie-Hellman dan nonce, dan yang ketiga membawa identitas plus hash autentikasi di bawah enkripsi yang baru saja dibentuk. RFC 2409 mendefinisikan konstruksinya: dengan autentikasi kunci pra-bagi, SKEYID diturunkan dari rahasia dan kedua nonce, dan materi kunci berikutnya dari SKEYID, nilai bersama Diffie-Hellman, cookie, dan konstanta.

Hash pada pesan kelima dan keenam dihitung atas nilai Diffie-Hellman, dua cookie, proposal, dan identitas pengirim, dengan SKEYID sebagai kunci. Penerima menghitung ulang dengan rahasia yang dikonfigurasi padanya. Ketidakcocokan mengakhiri pertukaran, dan rahasia itu sendiri tidak pernah menjadi payload.

Aggressive Mode memadatkan pekerjaan yang sama ke tiga pesan, yang berarti identitas dan hash autentikasi berjalan sebelum kanal terenkripsi ada. Itu paparan nyata untuk rahasia yang bisa ditebak, dan terpisah dari pertanyaan apakah rahasia itu dikirim. IKEv1 sudah usang menurut RFC 9395, jadi jejak lama adalah latihan diagnostik, bukan target penerapan.

IKEv2: turunan berbeda dan payload AUTH berbeda

IKEv2 tidak memakai ulang jadwal kunci IKEv1. Kunci IKE awal berasal dari benih yang dibangun dari nonce dan nilai bersama Diffie-Hellman, dan asosiasi keamanan anak diturunkan dari situ. Kunci pra-bagi sama sekali tidak memberi masukan pada benih.

Autentikasi kemudian muncul sebagai payload AUTH. Untuk autentikasi kunci bersama, RFC 7296 menetapkan bentuk rahasia yang dipad, diperoleh dengan melakukan hash pada rahasia dengan string tetap Key Pad for IKEv2, lalu melakukan hash pada data pertukaran yang ditandatangani dan identitas dengan kunci yang dipad itu. Pemverifikasi dapat membangun ulang nilai yang sama; pengamat tidak bisa, tanpa rahasia.

Perhatikan apa yang berubah. Pada IKEv1 rahasia ditanam ke dalam jadwal kunci sebelum hash autentikasi ada; pada IKEv2 jadwal kunci independen dari rahasia dan buktinya adalah payload terpisah yang terikat pada oktet yang ditandatangani. Jaminan konseptual sama, mesin berbeda, dan itulah sebabnya nama parameter dan rekaman tidak memetakan satu ke satu.

Apa yang sebenarnya dipelajari pengamat

Nilai publik Diffie-Hellman, proposal, nonce, dan cookie terlihat pada kedua versi. Identitas terlihat pada IKEv1 Aggressive Mode dan terlindungi pada kasus lain. Rahasia tidak pernah terlihat.

Kalimat terakhir punya batas yang layak disebut. Rahasia lemah yang dipilih manusia dapat diserang dengan menebak: penyerang menghitung nilai autentikasi untuk rahasia kandidat dan membandingkannya. IKEv1 Aggressive Mode membuat ini paling murah karena buktinya terbuka, dan standar memperingatkan tentang rahasia berentropi rendah secara umum. Tidak pernah mengirimkan rahasia bukan hal yang sama dengan membuat rahasia buruk menjadi aman.

Apa yang harus dilakukan dengan perbandingan ini

Gunakan satu rahasia unik per pasangan peer, hasilkan dari sumber acak, dan rotasikan melalui jalur penyediaan yang sama dengan yang mendistribusikannya. Jika rahasia tersimpan dalam templat konfigurasi yang dikirim ke setiap cabang, kompromi di satu lokasi adalah kompromi di semua lokasi.

Utamakan autentikasi berbasis sertifikat bila biaya operasionalnya dapat diterima, karena menghilangkan masalah menebak rahasia bersama dan memberi tiap peer identitas yang berbeda. Bila kunci pra-bagi tetap dipakai, buat panjang, batasi cakupannya, dan perlakukan versi IKE sebagai keputusan keamanan, bukan detail interoperabilitas.