Belajar Kerberos - Sejarah, Latar Belakang & Mengapa Membutuhkan Kerberos

#Pendahuluan

Di episode 0 kemarin kalian sudah menyiapkan fondasi: skill kriptografi, networking, dan lab topology dengan satu KDC serta dua client. Sekarang saatnya memahami mengapa Kerberos ada. Setiap protokol lahir untuk menjawab masalah nyata, dan Kerberos lahir dari salah satu masalah paling pelik di dunia jaringan: bagaimana membuktikan identitas tanpa mengirimkan kata sandi.

Episode ini akan membawa kalian kembali ke kampus MIT pada dekade 1980-an, mengenalkan tokoh-tokoh yang menjadi latar nama Kerberos, lalu membedah dengan teliti masalah-masalah autentikasi tradisional yang ingin dipecahkan. Di akhir episode, kalian akan paham mengapa Kerberos mendominasi enterprise — dan mengapa setiap arsitektur autentikasi modern masih berutang konsep pada protokol yang sudah berusia lebih dari 35 tahun ini.

#Sejarah: Lahir dari Project Athena

#Project Athena (1980-an)

Kerberos dikembangkan di MIT (Massachusetts Institute of Technology) pada pertengahan 1980-an sebagai bagian dari Project Athena — sebuah inisiatif ambisius untuk menghubungkan ribuan workstation di kampus ke layanan terpusat seperti email, penyimpanan file, dan print. Saat itu muncul pertanyaan praktis yang ternyata sangat sulit dijawab: bagaimana ribuan mahasiswa dan staf bisa mengakses banyak layanan jaringan dengan aman, tanpa admin harus mengelola ratusan kombinasi password, dan tanpa password yang melintasi jaringan sebagai teks mentah?

Jawabannya harus lebih baik daripada sekadar "kirim password ke server". Dibutuhkan protokol baru yang mampu membuktikan identitas secara kriptografis. Dari situlah Kerberos lahir.

#Mengapa Nama Kerberos

Nama Kerberos diambil dari Cerberus — dalam mitologi Yunani, anjing berkepala tiga yang menjaga gerbang Dunia Bawah (Hades). Penamaan ini bukan kebetulan: Kerberos bekerja dengan tiga pihak — client yang meminta akses, server yang menyediakan layanan, dan KDC yang memediasi kepercayaan. Tiga kepala, tiga peran, satu protokol yang menjaga gerbang masuk jaringan.

Penamaan ini juga mengingatkan kita pada salah satu prinsip desainnya: Kerberos adalah penjaga gerbang, bukan penjaga isi gedung. Dia memastikan hanya pihak yang berhak yang bisa lewat — persis seperti Cerberus menjaga gerbang, bukan menilai apa yang dilakukan orang di dalam.

#Evolusi Versi: Kerberos 4, 5, dan RFC 4120

1980-an   Project Athena dimulai, kebutuhan autentikasi terpusat muncul
1989      Kerberos 4 dirilis
1993      Kerberos 5 dirilis, distandarkan sebagai RFC 1510
2000-an   Microsoft mengadopsi Kerberos 5 untuk Active Directory
2005      RFC 4120 memperbarui spesifikasi Kerberos 5 (versi yang kita pakai)

Kerberos 4 adalah protokol pertama, tapi punya kelemahan signifikan: enkripsi lemah dan penanganan lifetime ticket yang terbatas. Kerberos 5 datang pada 1993 dengan perbaikan fundamental, kemudian distandarkan sebagai RFC 1510 oleh IETF. Pada 2005, spesifikasi diperbarui menjadi RFC 4120 yang menjadi rujukan utama implementasi modern — termasuk yang akan kalian install di episode 5.

#Masalah Autentikasi Tradisional

Sebelum Kerberos, autentikasi jaringan dilakukan dengan cara yang naif. Mari kita bedah masalah-masalahnya satu per satu — inilah alasan sebenarnya Kerberos dibutuhkan.

#Password Melintasi Jaringan sebagai Plaintext

Masalah paling mendasar: password dikirim langsung dari client ke server tanpa enkripsi. Siapa pun yang bisa menyadap jaringan — dengan tools seperti tcpdump atau Wireshark — bisa membaca password begitu saja. Ini seperti mengirim kode PIN kartu kredit lewat kartu pos terbuka.

#Replay Attack

Bahkan jika attacker tidak bisa membaca isi password, dia bisa merekam percakapan autentikasi dan memutar ulangnya nanti — disebut replay attack. Kalian login hari ini, attacker menyalin paketnya, dan minggu depan attacker "login" memakai salinan paket itu seolah-olah dia kalian.

#Kurangnya Mutual Authentication

Protokol tradisional memvalidasi client ke server, tapi tidak sebaliknya. Client tidak bisa membuktikan bahwa dia sedang berbicara dengan server yang benar, bukan server palsu yang dipasang attacker. Ini membuka pintu man-in-the-middle: attacker menyamar sebagai server, menangkap kredensial kalian, lalu meneruskannya ke server asli.

#Masalah Skalabilitas N x M

Tanpa otoritas terpusat, setiap layanan harus memverifikasi identitasnya sendiri — artinya setiap pasangan client-layanan butuh hubungan kredensial sendiri. Dengan N client dan M layanan, dibutuhkan N dikali M hubungan. Di perusahaan dengan 10.000 pengguna dan 500 layanan, itu berarti 5 juta kombinasi password yang harus dikelola. Tidak masuk akal.

Tanpa Kerberos (setiap pasangan butuh kredensial sendiri):
Client1 ──password──► Layanan A
Client1 ──password──► Layanan B
Client2 ──password──► Layanan A
Client2 ──password──► Layanan B   (4 hubungan untuk 2x2)
 
Dengan Kerberos (satu titik kepercayaan):
Client ──1x login──► KDC ──tiket──► Layanan A
                             ──tiket──► Layanan B   (Cukup 1 login)

#Password Reuse dan rhosts

Banyak layanan memakai password yang sama di banyak tempat, sehingga satu server yang bocor mengotori semuanya. Di dunia Unix awal, ada pula .rhosts — file yang menyatakan "siapa yang boleh login tanpa password berdasarkan alamat IP". Masalahnya jelas: alamat IP bisa dipalsukan (spoofing), sehingga kepercayaan berbasis IP sangat rapuh.

#Mengapa Kerberos

Kerberos menjawab semua masalah di atas dengan satu desain yang koheren:

• Single Sign-On (SSO) — login satu kali di KDC, lalu semua layanan di realm bisa diakses tanpa login ulang.
• Tidak ada password di jaringan — yang melintasi jaringan hanyalah ticket, bukan password. Password hanya dipakai secara lokal untuk menurunkan kunci.
• Mutual authentication — client dan server sama-sama membuktikan identitas (di episode 3 kita akan lihat AP_REP untuk sisi server).
• Kredensial terbatas waktu — setiap ticket punya masa berlaku; tidak seperti password yang berlaku selamanya.
• Autentikasi terpusat — KDC menjadi satu titik kebenaran, memecahkan masalah N dikali M.
• Enkripsi kuat — simetris, dengan jenis enkripsi yang bisa dipilih dan diperbarui (dari AES128 hingga AES256).
• Delegasi — ticket bisa diteruskan ke layanan lain secara terkontrol (konsep delegation yang akan dibahas di episode 20).

#Adopsi Luas: Dari Active Directory sampai SSH

Kerberos bukan protokol museum. Keputusan Microsoft untuk menjadikan Kerberos 5 sebagai mekanisme autentikasi inti Active Directory (mulai Windows 2000) membuatnya meroket menjadi standar de-facto enterprise. Saat ini Kerberos berjalan di:

• Active Directory — setiap login domain Windows adalah transaksi Kerberos.
• NFS — akses file jaringan dengan sec=krb5, krb5i, dan krb5p.
• SSH — autentikasi lewat GSSAPI tanpa password.
• Web — protokol SPNEGO/Negotiate untuk SSO di browser.
• Hadoop — keamanan kluster menggunakan Kerberos sebagai fondasi.
• Database — PostgreSQL dan MySQL mendukung autentikasi GSSAPI.
• Email — IMAP dan SMTP bisa memakai kredensial Kerberos lewat SASL.

Semua integrasi ini akan kita bedah satu per satu di fase 4 series ini, mulai episode 13.

#Penutup

Episode ini menjelaskan asal-usul Kerberos dan alasan keberadaannya. Kerberos lahir dari Project Athena MIT pada 1980-an, dinamai dari anjing berkepala tiga Cerberus, dan melewati evolusi dari Kerberos 4, Kerberos 5 (RFC 1510), hingga RFC 4120 pada 2005. Ia menjawab masalah autentikasi tradisional — password plaintext, replay attack, kurangnya mutual authentication, masalah N dikali M, dan ketergantungan pada .rhosts — dengan SSO, tiket terenkripsi, kredensial terbatas waktu, dan autentikasi terpusat.

Poin penting yang harus kalian bawa:

• Kerberos adalah jawaban atas masalah N dikali M dan password yang melintasi jaringan.
• Tiga pihak (client, KDC, server) adalah DNA protokol ini — nama Cerberus bukan sekadar mitos.
• RFC 4120 adalah spesifikasi modern yang menjadi rujukan seluruh implementasi.
• Adopsi oleh Active Directory adalah alasan utama dominasinya di dunia enterprise.

Di episode 2 selanjutnya kita akan membongkar arsitektur Kerberos dan core concepts — apa itu realm, principal, KDC, ticket, TGT, session key, dan trust model. Konsep inilah yang akan menjadi bahasa bersama untuk semua episode praktik berikutnya. Sampai jumpa di episode berikutnya!