Dua identitas dalam satu login IKEv2: mesin dulu, lalu pengguna

Sertifikat klien divalidasi, pertukaran pertama selesai, lalu koneksi berhenti dengan galat tentang putaran autentikasi tambahan. Tidak ada yang salah pada rantai sertifikat dan tidak ada yang berubah di jaringan. Gateway dikonfigurasi untuk menuntut bukti kedua dari sisi yang terhubung, dan klien tidak pernah mengirimkannya. Memutuskan siapa membuktikan apa, dan dalam urutan apa, adalah seluruh tugasnya, dan itu dimulai dengan membaca kebijakan dari titik akhir tempat Anda berdiri. Dua bukti berbeda jenis, dalam urutan tetap, adalah keputusan desain, bukan kotak centang.

Gejalanya: kegagalan setelah bukti pertama yang berhasil

Pertukaran pertama selesai dan log tampak sehat, sampai gateway meminta identitas pengguna melalui EAP. Saat itu jabat tangan terhenti atau mengembalikan galat protokol yang menyebut putaran tambahan. Sertifikat mesin yang sepenuhnya valid ditolak karena alasan yang tidak ada hubungannya dengan validitasnya. Kebijakan meminta bukti kedua, dan jawaban klien tidak pernah datang.

Kedua gambaran kegagalan itu akurat tergantung di mana Anda berdiri. Dari sisi klien tampak seperti server yang menolak sertifikat valid, dan dari sisi server tampak seperti klien yang tidak bisa menyelesaikan login. Peristiwa yang sama terbaca sebagai masalah kepercayaan di satu log dan masalah kemampuan di log lain. Hanya kebijakan yang dikonfigurasi yang memberi tahu Anda mana yang benar.

Apa yang ditambahkan ekstensi ini dan apa yang tidak

IKEv2 membawa ekstensi untuk menjalankan lebih dari satu pertukaran autentikasi dalam satu sesi. RFC 4739 menggambarkan, di antara urutan lain, klien yang membuktikan identitas sertifikat lalu mengautentikasi seseorang melalui EAP. Dokumen itu berstatus Experimental, yang berarti tidak ada implementasi yang berutang fitur ini kepada Anda. Jangan mengasumsikan apa pun tentang dukungan sampai rekan bernegosiasi untuknya.

Kedua sisi harus mendukung ekstensi dan menyetujuinya selama pertukaran. Gateway yang dikonfigurasi untuk putaran kedua tidak dapat memaksa klien menjalankannya, dan klien yang mendukungnya tidak akan memakainya kecuali server meminta. Asimetri itulah sebabnya kegagalan biasanya muncul sebagai batas waktu atau galat protokol alih-alih pernyataan jelas tentang kemampuan. Membaca konfigurasi satu sisi memberi tahu Anda separuh dari apa yang akan terjadi.

Satu bukti per titik akhir adalah bentuk yang lazim, dan ini bukan desain itu. Gateway menampilkan sertifikatnya, pengguna menjawab lewat EAP, dan setiap sisi telah mengautentikasi sisi lain tepat satu kali. Kedua bukti itu datang dari titik akhir yang berlawanan, jadi tidak satu pun mengatakan sesuatu yang terpisah tentang mesin dan orang yang memakainya.

EAP-TLS adalah bentuk ketiga, dan itu juga bukan ini. Di sana sertifikat klien ditampilkan di dalam metode EAP, sehingga klien tetap menyelesaikan satu autentikasi IKE. Kredensialnya bisa tampak identik dengan kasus banyak putaran sementara protokol membawa satu putaran alih-alih dua. Karena itu desain yang disalin dari penerapan EAP-TLS gagal tepat di titik tempat bukti kedua diharapkan.

Berkas yang sama terbaca berbeda di gateway

Berkas swanctl yang sama terbaca berbeda tergantung di mana ia berjalan, dan itulah bagian yang membuat orang tersandung. Di laptop gateway adalah rekannya, dan di gateway laptop adalah rekannya, jadi tulis sisi local sebagai siapa saya dan sisi remote sebagai siapa yang akan saya terima. Blok local menjelaskan bagaimana titik akhir ini mengautentikasi dirinya, dan blok remote menyatakan apa yang dituntutnya dari ujung lain. Menyalin blok antara dua berkas membalik maknanya tanpa mengubah satu karakter pun. Membandingkan kedua berkas hampir tidak memberi tahu apa pun, karena kata yang sama berarti berlawanan di masing-masing.

Posisi sebuah bagian menentukan urutannya kecuali nomor putaran menimpanya. Karena itu bagian local atau remote tambahan menggambarkan putaran tambahan, bukan alternatif, dan nomor putaran eksplisit di referensi swanctl.conf ada justru untuk membuat urutan itu disengaja. Tanpanya, memindahkan blok mengubah perilaku. Karena itu pula dua konfigurasi yang tampak setara di atas kertas dapat berperilaku dalam urutan berlawanan.

Aturan urutan itu menghasilkan mode kegagalan yang layak diingat. Blok remote kedua bukan pilihan lain yang dapat diterima; itu tuntutan kedua, karena itu kebijakan yang terbaca seperti atau/atau berperilaku seperti dan-lalu. Kebijakan gateway dapat menerima sertifikat mesin yang terdaftar lalu menuntut pertukaran EAP pengguna itu, dalam urutan tersebut.

Bedakan putaran dari faktor independen

Dua putaran tidak otomatis dua faktor independen. Mengulang bukti, atau menyimpan dua kredensial di penyimpanan yang sama, tidak memberikan kekuatan yang seharusnya ditambahkan desain itu. Independensi adalah sifat dari bagaimana rahasia disimpan dan apa yang membahayakannya, bukan dari berapa banyak pertukaran yang dijalankan protokol. Desain yang menghitung putaran sebagai faktor melebih-lebihkan apa yang dimilikinya. Perbedaan itu paling penting ketika pertanyaan kepatuhan menanyakan berapa faktor yang benar-benar dipakai login.

Sertifikat mesin membuktikan kepemilikan kuncinya yang diterima, dan tidak lebih. Itu bukan atestasi perangkat keras dan bukan laporan kesehatan perangkat, jadi kebijakan yang membutuhkan informasi postur membutuhkan mekanisme lain. Kolom subject juga bukan label inventaris yang bisa dipercaya, karena subject dipilih oleh siapa pun yang menerbitkan atau mendaftarkan sertifikat. Jika desain membutuhkan bukti bahwa mesin itu sehat, bukti itu harus datang dari komponen yang mengukur mesin.

Tuliskan apa yang sebenarnya dibuktikan setiap putaran sebelum menambahkannya. Ketika dua putaran membuktikan hal yang sama dua kali, yang kedua menambah latensi dan tiket dukungan alih-alih keyakinan. Catatan itu juga yang menghentikan perdebatan tentang apakah putaran tambahan itu sepadan dengan biayanya.

Tulis aturan pemasangan dan uji penolakannya

Putuskan identitas mesin mana yang boleh dipasangkan dengan orang mana, dan tulis aturannya di tempat penegakan berada. Dua kredensial valid yang bersebelahan tidak membuktikan apa pun tentang pemasangan, karena pemasangan adalah keputusan otorisasi, bukan hasil autentikasi. Catatan pendaftaran atau backend autentikasi harus menegakkan hubungan yang diinginkan organisasi.

Lalu uji apa yang seharusnya gagal: pengguna yang diterima di mesin yang tidak disetujui, pengguna yang tidak disetujui yang memegang kredensial mesin, dan rekan yang tidak dapat melakukan putaran tambahan. Jika ketiganya diam-diam mendapat akses yang sama, kebijakan itu menggambarkan niat alih-alih menegakkannya. Bandingkan konfigurasi yang dinyatakan dengan apa yang dilaporkan daemon, karena koneksi yang tidak pernah cocok terlihat sama dengan aturan yang lolos:

swanctl --list-conns
swanctl --list-sas

Periksa putaran yang dinegosiasikan dan otorisasi yang dihasilkannya, bukan hanya login yang berhasil. Dan jangan meraih pengaturan IKEv1 XAuth lama sebagai jalan pintas: cocokkan protokol, peran, urutan, dan perilaku nyata klien alih-alih menghapus putaran yang diperlukan sampai koneksi berhasil. Menghapus putaran yang gagal adalah cara desain dua bukti diam-diam menjadi desain satu bukti yang tidak ditinjau siapa pun. Simpan penghapusan itu di catatan perubahan.