Belajar Kerberos - Kerberos Encryption Types

#Pendahuluan

Di episode 10, kalian memasang trust cross-realm dan menyadari satu syarat diam-diam: kedua KDC harus punya daftar enctype yang sama agar shared secret krbtgt menghasilkan kunci yang cocok. Episode 11 ini membahas fondasi yang memungkinkan semua itu: encryption types — algoritma yang melindungi seluruh pesan Kerberos, dari TGT sampai service ticket. Di episode-episode awal kalian sudah menyentuh dasar kunci, password, dan keytab; sekarang kita menelusuri daftar enctype secara utuh, cara mengonfigurasinya, bagaimana negosiasinya bekerja, serta strategi migrasi dari enkripsi lemah menuju AES murni.

#Ikhtisar Encryption Types

#Enctype Legacy yang Harus Ditinggalkan

• DES — des-cbc-crc, deprecated. Kunci 56-bit yang bisa dibobol brute force dalam hitungan jam; sudah tidak aman sama sekali.
• 3DES — des3-cbc-sha1, legacy. Upgrade DES yang kini juga dianggap usang dan lambat.
• RC4-HMAC — arcfour-hmac, legacy. Sangat populer di ekosistem Microsoft karena dipakai untuk akun service dan kompatibilitas lama, tetapi kriptografinya sudah lama dipertanyakan.

#Enctype AES

• AES128 — aes128-cts-hmac-sha1-96, AES 128-bit.
• AES256 — aes256-cts-hmac-sha1-96, AES 256-bit, enctype default di MIT Kerberos.
• AES-SHA2 modern — aes128-cts-hmac-sha256-128 dan aes256-cts-hmac-sha384-192, varian berbasis SHA-256 dan SHA-384 yang lebih ramah untuk kepatuhan FIPS.

#Enctype Lain

• Camellia — camellia128-cts-cmac dan camellia256-cts-cmac, standar kriptografi Jepang. Jarang dipakai di praktik karena dukungan klien yang terbatas dan minim akselerasi hardware.

#Tabel Perbandingan Enctype

#Mengonfigurasi Enkripsi

#Enctype yang Didukung KDC

Di sisi KDC, daftar enctype ditentukan supported_enctypes di /etc/krb5kdc/kdc.conf. Daftar ini juga menentukan kunci apa saja yang diturunkan saat sebuah principal dibuat — karena itu mengubahnya tidak langsung memengaruhi principal yang sudah ada.

Daftar enctype di /etc/krb5kdc/kdc.conf

[realms]
    EXAMPLE.COM = {
        supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
    }

#Daftar Enctype di Sisi Klien

[libdefaults] pada /etc/krb5.conf mengatur tiga daftar sekaligus:

• default_tkt_enctypes — enctype yang diminta untuk TGT.
• default_tgs_enctypes — enctype yang diminta untuk service ticket.
• permitted_enctypes — enctype yang boleh dipakai untuk TGT maupun service ticket.

#Hanya Enkripsi Kuat

Hanya enctype kuat di /etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.COM
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    allow_weak_crypto = false

allow_weak_crypto = false menolak enctype DES dan RC4 secara total. Saat bernilai true, enctype lemah ikut ditawarkan dalam negosiasi — praktik yang sebaiknya tidak dipakai di produksi.

#Negosiasi Enkripsi

#Permintaan Klien

Saat kinit, klien mengirim daftar enctype pilihannya (dari default_tkt_enctypes) kepada KDC. KDC lalu memilih enctype terkuat yang termasuk dalam daftar itu dan yang dimiliki kunci principal-nya.

#Kemampuan Server

Service ticket dienkripsi dengan kunci dari principal tujuan. Jika principal tujuan tidak memiliki kunci untuk enctype yang diminta — misalnya keytab lama yang hanya berisi RC4 — maka KDC hanya bisa memakai enctype yang tersedia. Irisan antara default_tkt_enctypes di sisi klien, permitted_enctypes, dan supported_enctypes di sisi KDC menentukan apa yang benar-benar bisa dipakai.

#Mekanisme Fallback

Kerberos mencoba enctype satu per satu sesuai urutan preferensi. Jika tidak ada satu pun yang cocok, KDC membalas dengan kesalahan KDC_ERR_ETYPE_NOSUPP, dan kinit gagal. Inilah fallback yang sebenarnya: bukan menurun ke enctype lemah, melainkan menolak ketika tidak ada titik temu.

#Masalah Kompatibilitas

Masalah klasik muncul ketika klien atau layanan masih jadul: aplikasi lama yang hanya mendukung RC4 tidak bisa berkomunikasi dengan KDC yang sudah AES-only, dan begitu juga sebaliknya. Saat menyingkirkan enctype lama, pastikan semua klien, server, dan keytab sudah siap — atau siapkan periode transisi dengan dua daftar enctype sekaligus.

#Pertimbangan Keamanan

#Mematikan Enkripsi Lemah

Aturan pertama: jangan pernah membiarkan DES, 3DES, atau RC4 hidup di realm yang sudah kalian kuasai. Kehadiran satu layanan yang memakai RC4 memberikan titik serang yang bisa diarahkan ke seluruh realm, terutama dalam serangan Kerberoasting yang akan dibahas di episode 21. Dengan allow_weak_crypto = false, krb5.conf menutup pintu itu.

#AES vs RC4

#Implikasi Performa

AES 128-bit hampir selalu cukup untuk skala normal, dan dengan dukungan AES-NI di CPU modern biayanya nyaris nol. aes256-cts-hmac-sha384-192 sedikit lebih berat karena HMAC-SHA-384-nya, tetapi tetap jauh lebih ringan dibanding 3DES. Camellia jarang diakselerasi hardware, sehingga dalam praktik justru terasa lebih lambat — inilah alasan ia jarang dipilih.

#Kepatuhan FIPS

Di lingkungan yang wajib FIPS, DES, RC4, dan 3DES tidak diterima. AES 128-bit dan 256-bit, termasuk varian AES-SHA2 yang lebih baru, adalah pilihan yang sesuai. Karena itu untuk pengadaan baru, arahkan langsung ke aes256-cts-hmac-sha1-96 atau varian AES-SHA2 modern.

#Strategi Migrasi

#Meng-upgrade Enctype

Migrasi dilakukan bertahap: tambahkan dulu enctype baru ke daftar yang didukung, biarkan enctype lama tetap ada, lalu hapus yang lama setelah semua pihak terbukti kompatibel. Perlu diingat, perubahan di supported_enctypes hanya berlaku untuk principal yang dibuat sesudahnya — principal lama butuh pengaturan ulang kunci.

#Mendukung Beberapa Enctype

Selama transisi, jalankan dua daftar sekaligus: permitted_enctypes memuat enctype baru dan lama, sementara KDC tetap mengeluarkan enctype baru untuk principal yang mampu. Untuk keytab, ekspor ulang dengan enctype baru agar service dapat memakai kunci AES:

sudo kadmin.local -q "ktadd -k /etc/krb5kdc/http.keytab -e aes256-cts-hmac-sha1-96 host/www@EXAMPLE.COM"

#Menguji Kompatibilitas

Gunakan kinit -e untuk memaksa satu enctype tertentu saat pengujian:

kinit -e aes256-cts-hmac-sha1-96 budi
klist -e

Dengan kinit -e aes256-cts-hmac-sha1-96 kalian membuktikan bahwa jalur menuju TGT berfungsi untuk enctype itu, dan klist -e memverifikasi hasilnya.

#Migrasi Paksa

Ketika semua pihak sudah siap, lakukan migrasi paksa: hapus enctype lama dari ketiga daftar, setel allow_weak_crypto = false, lalu paksa kunci principal diperbarui. Untuk principal dengan password, gunakan cpw -e agar kunci diturunkan ulang dengan daftar enctype baru; untuk principal berkeytab, ekspor ulang keytabnya. Setelah itu, klien dengan enctype lama otomatis tidak bisa lagi terhubung.

Kondisi akhir: AES modern saja

[libdefaults]
    default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    allow_weak_crypto = false

#Penutup

Pada episode 11 ini, kalian mengenal seluruh keluarga encryption type Kerberos: DES, 3DES, dan RC4 yang harus ditinggalkan; keluarga AES beserta varian SHA-2 modern; cara menetapkan daftar enctype di kdc.conf dan krb5.conf; proses negosiasi dari permintaan klien hingga kemampuan server; pertimbangan keamanan termasuk kepatuhan FIPS; serta strategi migrasi bertahap sampai migrasi paksa menuju AES murni.

Inti yang harus dibawa pulang:

• Legacy bukan sekadar kuno — des-cbc-crc, des3-cbc-sha1, dan arcfour-hmac adalah risiko nyata, bukan sekadar peninggalan.
• Negosiasi adalah irisan — KDC hanya memakai enctype yang diminta klien dan dimiliki kunci principal tujuan.
• Migrasi bertahap, lalu perbarui kunci — ktadd -e dan cpw -e adalah alat untuk membarui kunci lama ke enctype baru.
• kinit -e aes256-cts-hmac-sha1-96 adalah alat pengujian utama selama masa transisi.

Enkripsi yang kuat saja belum cukup — di episode 12 berikutnya kita mengunci pintu yang paling awal: preauthentication dan FAST, bagaimana Kerberos membuktikan identitas sebelum menerbitkan tiket dan membungkus seluruh pertukarannya dalam tunnel terenkripsi.