Belajar Kerberos - Kerberos Authentication Flow - Deep Dive

#Pendahuluan

Di episode 2 kalian sudah mengenal peta arsitektur Kerberos: client, KDC (AS + TGS + database), service server, serta konsep principal, realm, dan ticket. Sekarang saatnya menyalakan mesinnya. Episode ini akan membedah alur autentikasi Kerberos — perjalanan yang dimulai dari kalian mengetik kinit dan berakhir dengan akses ke sebuah layanan.

Alur ini terdiri dari tiga pertukaran pesan yang berurutan: AS-REQ/AS-REP (autentikasi awal), TGS-REQ/TGS-REP (meminta tiket layanan), dan AP-REQ/AP-REP (mengakses service). Sepanjang perjalanan kita akan melihat bagaimana session key lahir, bagaimana authenticator mencegah penyalahgunaan, dan bagaimana timestamp menjaga semuanya tetap segar. Mari kita mulai dari gambaran besar.

#Gambaran Umum: Tiga Pertukaran Pesan

Klien                KDC (AS/TGS)                 Service
  │ 1. AS-REQ (identitas + timestamp)                 │
  ├──────────────────►                                │
  │ 2. AS-REP (TGT + session key TGS)                 │
  │◄──────────────────                                 │
  │ 3. TGS-REQ (TGT + nama service)                   │
  ├──────────────────►                                │
  │ 4. TGS-REP (service ticket + session key)         │
  │◄──────────────────                                 │
  │ 5. AP-REQ (service ticket + authenticator)        │
  ├───────────────────────────────────────────────────►
  │ 6. AP-REP (opsional: bukti identitas service)     │
  │◄───────────────────────────────────────────────────

#AS-REQ / AS-REP: Autentikasi Awal

Semuanya dimulai ketika kalian menjalankan kinit. Inilah pertukaran pertama:

1. Client mengirim AS-REQ ke Authentication Server. Pesan berisi identitas principal dan preauthentication — biasanya timestamp yang dienkripsi dengan kunci jangka panjang client. Ini membuktikan bahwa client benar-benar tahu passwordnya, tanpa mengirim password ke jaringan.

2. AS memverifikasi timestamp dengan kunci client yang disimpan di database. Jika cocok, AS percaya client adalah pemilik principal tersebut.

3. AS membuat session key baru untuk client dan TGS — sebut saja K_c,tgs — lalu membungkusnya menjadi dua paket:

   • TGT, dienkripsi dengan kunci TGS (K_tgs), berisi session key K_c,tgs dan data masa berlaku.
   • Session key K_c,tgs, dienkripsi dengan kunci jangka panjang client.

4. Client menerima AS-REP, mendekripsi session key dengan kunci turunan dari passwordnya. Kini client punya TGT dan session key TGS.

Perhatikan yang penting: password tidak pernah dikirim. Yang melintasi jaringan hanyalah blok terenkripsi yang hanya bisa dibuka oleh pemegang kunci yang benar.

#TGS-REQ / TGS-REP: Meminta Tiket Layanan

TGT saja tidak cukup — service akan menolak TGT. Client harus menukar TGT menjadi service ticket khusus untuk service yang dituju:

1. Client mengirim TGS-REQ ke Ticket Granting Server berisi TGT, nama service yang dituju (SPN, misalnya host/client1.example.com), dan sebuah authenticator.

2. TGS membuka TGT dengan kunci TGS (K_tgs). Isi TGT menyatakan client telah login dan berisi session key K_c,tgs.

3. TGS memvalidasi authenticator menggunakan K_c,tgs yang diambil dari TGT. Ini membuktikan bahwa pemegang TGT memang benar-benar client (bukan pencuri tiket), karena hanya client yang punya K_c,tgs.

4. TGS membuat session key baru untuk client dan service — sebut saja K_c,s — lalu membungkusnya:

   • Service ticket, dienkripsi dengan kunci service (K_s), berisi K_c,s dan identitas client.
   • Session key K_c,s, dienkripsi dengan K_c,tgs.

5. Client menerima TGS-REP, membuka K_c,s dengan K_c,tgs. Kini client punya service ticket dan session key service.

Keindahan desain ini: client tidak pernah melihat kunci service, dan service tidak pernah melihat kunci TGS. Setiap pihak hanya tahu bagian yang menjadi haknya.

#AP-REQ / AP-REP: Mengakses Service

Sekarang client berbicara langsung dengan service:

1. Client mengirim AP-REQ ke service berisi service ticket dan sebuah authenticator baru — timestamp yang dienkripsi dengan session key K_c,s.

2. Service membuka service ticket dengan kunci jangka panjangnya (K_s), mengambil K_c,s dan identitas client.

3. Service memvalidasi authenticator dengan K_c,s. Karena authenticator dienkripsi dengan session key yang hanya diketahui client dan service, service yakin pengirimnya adalah client yang sah.

4. AP-REP (opsional) — untuk mutual authentication, service mengirim balik authenticator-nya sendiri (timestamp yang dienkripsi dengan K_c,s). Client membukanya dan kini yakin dia berbicara dengan service yang benar, bukan penipu.

5. Sejak saat ini, semua komunikasi antara client dan service dienkripsi menggunakan session key K_c,s.

#Authenticator, Timestamp, dan Replay Cache

Authenticator adalah pahlawan tanpa tanda jasa di balik keamanan Kerberos. Ia adalah blok kecil berisi identitas client dan timestamp, dienkripsi dengan session key yang sedang berlaku. Authenticator membuktikan dua hal sekaligus:

• Pemegang tiket benar-benar memiliki session key (bukti kepemilikan).
• Permintaan ini segar — bukan rekaman lama (bukti ketepatan waktu).

Karena timestamp itulah sinkronisasi jam menjadi kritis — topik yang akan kita bedah menyeluruh di episode 4. Service menyimpan timestamp-timestamp yang sudah diterima dalam replay cache: jika ada timestamp yang sama muncul lagi (tanda replay attack), permintaan langsung ditolak.

#Session Key dan Forward Secrecy

Setiap pertukaran melahirkan session key baru yang hanya hidup untuk satu sesi: K_c,tgs untuk komunikasi client-TGS, lalu K_c,s untuk komunikasi client-service. Setelah sesi berakhir, kunci dibuang.

Sifat ini memberi forward secrecy dalam skala terbatas: jika sebuah session key bocor, attacker hanya bisa membaca percakapan sesi itu — bukan percakapan masa lalu yang memakai kunci berbeda, apalagi seluruh kredensial jangka panjang. Membocorkan satu kunci hotel tidak otomatis membuka semua kamar di gedung itu.

#SPNEGO: Pembungkus di Dunia Nyata

Dalam aplikasi nyata — terutama web — Kerberos jarang berbicara langsung. Ia dibungkus oleh SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). SPNEGO adalah mekanisme negosiasi di atas GSSAPI yang memungkinkan client dan server menyepakati mekanisme autentikasi bersama, dan Kerberos adalah mekanisme yang paling sering dipilih.

Saat browser dan server berkomunikasi lewat HTTP, header Authorization: Negotiate ... yang membawa token SPNEGO — di dalamnya tersembunyi AP-REQ Kerberos. Inilah fondasi SSO web yang akan kita bedah di episode 15 tentang SPNEGO/Negotiate.

#Sifat Keamanan yang Dijamin

Ringkasan keamanan yang diberikan alur di atas:

• Password tidak pernah melintasi jaringan — yang berjalan hanya tiket dan authenticator terenkripsi.
• Ticket terbatas waktu — setiap tiket punya masa berlaku, sehingga tidak abadi seperti password.
• Replay attack ditolak — timestamp + replay cache membuat salinan paket lama tidak berguna.
• Mutual authentication — AP-REP memastikan client dan service sama-sama terverifikasi.
• Session key memberi isolasi — satu kunci bocor tidak membuka sesi lain.

Jika kalian ingin melihat alur ini secara langsung, jalankan KRB5_TRACE=1 kinit di lab — Kerberos akan mencetak jejak kriptografis setiap langkah AS dan TGS, persis seperti yang kita bedah di atas.

#Penutup

Episode ini membedah alur autentikasi Kerberos dari kinit hingga akses service: AS-REQ/AS-REP menerbitkan TGT dan session key pertama, TGS-REQ/TGS-REP menukar TGT menjadi service ticket, dan AP-REQ/AP-REP mengakses service dengan mutual authentication. Sepanjang perjalanan, authenticator dan timestamp menjaga keaslian dan kesegaran setiap permintaan, replay cache menolak serangan ulang, dan SPNEGO membungkus semuanya untuk aplikasi web.

Poin penting yang harus kalian bawa:

• Tiga pertukaran: AS (login), TGS (tukar TGT), AP (akses service).
• Authenticator = identitas + timestamp, dienkripsi dengan session key.
• Timestamp + replay cache adalah benteng melawan replay attack — dan alasan mengapa waktu harus sinkron.
• SPNEGO membungkus Kerberos untuk aplikasi web (detail di episode 15).

Di episode 4 selanjutnya kita akan menangani dua prasyarat infrastruktur yang paling sering merusak semua alur ini: DNS dan sinkronisasi waktu. Kita akan menyiapkan NTP dengan chrony, konfigurasi krb5.conf, record SRV untuk penemuan KDC, hingga troubleshooting error Clock skew too great. Pastikan lab kalian siap — episode ini penuh praktik!