Kerberos (protokol)

MIT mengembangkan Kerberos untuk melindungi layanan jaringan yang disediakan oleh Project Athena. Protokol ini dinamai sesuai dengan karakter mitologi Yunani Kerberos (atau Cerberus), yang dikenal dalam mitologi Yunani sebagai anjing penjaga berkepala tiga yang mengerikan dari Hades. Ada beberapa versi protokol; versi 1-3 hanya digunakan secara internal di MIT.

Steve Miller dan Clifford Neuman, perancang utama Kerberos versi 4 (yang menggunakan algoritma enkripsi DES dengan kunci 56-bit), mempublikasikan versi tersebut pada tahun 1989, meskipun mereka telah menargetkannya terutama untuk Project Athena.

Versi 5, didesain oleh John Kohl dan Clifford Neuman, muncul sebagai RFC 1510 pada tahun 1993 (dibuat usang oleh RFC 4120 pada tahun 2005), dengan tujuan mengatasi keterbatasan dan masalah keamanan Versi 4. MIT membuat implementasi Kerberos Versi 5 tersedia secara bebas, di bawah lisensi perangkat lunak yang mirip dengan yang digunakan oleh lisensi BSD.

Beberapa perusahaan menggunakan Kerberos Versi 5 dalam perangkat lunak komersial, termasuk:

·         Microsoft Windows 2000 dan yang lebih baru menggunakan Kerberos sebagai metode otentikasi default mereka.
Beberapa tambahan Microsoft pada rangkaian protokol Kerberos didokumentasikan dalam RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 mendokumentasikan penggunaan cipher RC4
 oleh Microsoft.
Sementara Microsoft menggunakan protokol Kerberos, Microsoft tidak menggunakan perangkat lunak MIT.[1]

·         Mac OS X Apple juga menggunakan Kerberos dalam versi klien dan servernya.

·         Red Hat Linux versi 4 dan yang lebih baru menggunakan Kerberos baik dalam versi klien maupun server.

Pada tahun 2005, kelompok kerja IETF Kerberos memperkenalkan spesifikasi baru yang diperbarui untuk Kerberos Versi 5 [2]. pembaruan meliputi:

·         "Spesifikasi Enkripsi dan Checksum" (RFC 3961),

·         "Enkripsi Advanced Encryption Standard (AES) untuk Kerberos 5" (RFC 3962),

·         Edisi baru dari spesifikasi Kerberos Versi 5 "Layanan Otentikasi Jaringan Kerberos (V5)" (RFC 4120). Versi ini menggantikan RFC 1510, mengklarifikasi aspek-aspek protokol dan penggunaan yang dimaksudkan dalam penjelasan yang jelas dan lebih rinci,

·         Edisi baru dari spesifikasi GSS-API "Mekanisme Antarmuka Program Aplikasi Layanan Keamanan Generik Kerberos Versi 5 (GSS-API): Versi 2." (RFC 4121).

Pada tahun 2007, MIT membentuk Konsorsium Kerberos untuk kelanjutan pengembangan.

Kerberos menggunakan protokol Needham-Schroeder sebagai dasarnya. Kerberos menggunakan otentikasi pihak ketiga yang terpercaya yang dikenal sebagai "key distribution center (KDC)", yang terdiri dari dua bagian yang terpisah secara logis: Authentication Server (AS) dan Ticket Granting Server (TGS). Kerberos bekerja berdasarkan "tiket" (disebut tiket Kerberos) yang berfungsi untuk membuktikan identitas pengguna.

Basis data Kerberos: Pusat distribusi kunci (KDC) memelihara database kunci rahasia; setiap entitas di jaringan - baik klien atau server - berbagi kunci rahasia yang hanya diketahui oleh dirinya sendiri dan KDC. Pengetahuan tentang kunci ini berfungsi untuk membuktikan identitas setiap entitas. Untuk komunikasi antara dua entitas, KDC menghasilkan kunci sesi yang dapat mereka gunakan untuk mengamankan komunikasi mereka.

Istilah "server Kerberos" umumnya mengacu pada KDC. Untuk tujuan keandalan, dimungkinkan untuk memiliki KDC cadangan. Ini disebut sebagai "server budak Kerberos". Semua slave menyinkronkan database mereka dari server master Kerberos.

Istilah "server aplikasi Kerberized" umumnya mengacu pada program Kerberized yang dikomunikasikan klien dengan menggunakan tiket Kerberos untuk otentikasi. Misalnya, server telnet Kerberos adalah contoh server aplikasi Kerberized . Sementara istilah "aplikasi Kerberized" digunakan untuk merujuk ke sisi klien server aplikasi Kerberized, Misalnya, klien telnet Kerberos adalah contoh aplikasi Kerberized.

Keamanan protokol sangat bergantung pada:

1. Peserta mempertahankan waktu yang disinkronkan secara longgar.
2. Deklarasi keaslian yang berumur pendek: tiket Kerberos.

Deskripsi protokol yang disederhanakan

Singkatan berikut ini akan digunakan:

·         AS = Server Otentikasi

·         TGS = Server Pemberian Tiket

·         SS atau Server = Service Server (Pengguna server yang meminta layanannya, seperti print server, file server, dll...)

·         TGT = Ticket Granting Ticket (tiket Kerberos untuk TGS. Disiapkan oleh AS, kemudian digunakan untuk berbicara dengan TGS).

Secara singkat, klien mengautentikasi ke AS menggunakan shared secret jangka panjang dan menerima tiket dari AS. Kemudian klien dapat menggunakan tiket ini untuk mendapatkan tiket tambahan untuk SS menggunakan shared secret yang sama. Tiket ini dapat digunakan untuk membuktikan otentikasi ke SS.

Protokol secara lebih terperinci

Langkah-langkah Logon berbasis Klien Pengguna:

1. Seorang pengguna memasukkan nama pengguna dan kata sandi pada mesin klien.
2. Klien melakukan fungsi satu arah (kebanyakan fungsi Hash) pada kata sandi yang dimasukkan, dan ini menjadi kunci rahasia klien/pengguna.

Langkah-langkah Autentikasi Klien:

1. Klien mengirimkan pesan cleartext ke AS yang meminta layanan atas nama pengguna.
   Contoh pesan: "Pengguna XYZ ingin meminta layanan".
   Catatan: Baik kunci rahasia maupun kata sandi tidak dikirim ke AS.
2. AS memeriksa untuk melihat apakah klien ada dalam database-nya. Jika ya, AS mengirimkan kembali dua pesan berikut ini ke klien:
• Pesan A: Kunci Sesi Klien/TGS dienkripsi menggunakan kunci rahasia klien/pengguna.
• Pesan B: TGT (yang mencakup ID klien, alamat jaringan klien, periode validitas tiket, dan Kunci Sesi Klien/TGS) dienkripsi dengan menggunakan kunci rahasia TGS.
3. Setelah klien menerima pesan A dan B, klien mendekripsi pesan A untuk mendapatkan Kunci Sesi Klien/TGS. Kunci sesi ini digunakan untuk komunikasi lebih lanjut dengan TGS. Pada titik ini, klien memiliki informasi yang cukup untuk mengotentikasi dirinya sendiri ke TGS.
   Catatan: Klien tidak dapat mendekripsi Pesan B, karena dienkripsi menggunakan kunci rahasia TGS.

Langkah-langkah Otorisasi Layanan Klien:

1. Apabila meminta layanan, klien mengirimkan dua pesan berikut ini ke TGS:
• Pesan C: Terdiri dari TGT dari pesan B dan ID dari layanan yang diminta.
• Pesan D: Authenticator (yang terdiri dari ID klien dan timestamp), dienkripsi menggunakan Kunci Sesi Klien/TGS.
2. Setelah menerima pesan C dan D, TGS mengambil pesan B dari pesan C. TGS mendekripsi pesan B menggunakan kunci rahasia TGS. Ini memberikan Kunci Sesi Klien/TGS. Dengan menggunakan kunci ini, TGS mendekripsi pesan D (Authenticator) dan mengirimkan dua pesan berikut ini kepada klien:
• Pesan E: Tiket Klien-ke-Server (yang mencakup ID klien, alamat jaringan klien, masa berlaku dan Kunci Sesi Klien/Server) dienkripsi menggunakan kunci rahasia SS.
• Pesan F: Kunci Sesi Klien/Server dienkripsi dengan Kunci Sesi Klien/TGS.

Langkah-langkah Permintaan Layanan Klien:

1. Setelah menerima pesan E dan F dari TGS, klien memiliki informasi yang cukup untuk mengotentikasi dirinya sendiri ke SS. Klien terhubung ke SS dan mengirimkan dua pesan berikut:
• Pesan E: dari langkah sebelumnya (tiket Klien-ke-Server, dienkripsi menggunakan kunci rahasia SS).
• Pesan G: Authenticator baru, yang mencakup ID klien, cap waktu dan dienkripsi menggunakan Kunci Sesi Klien/Server.
2. SS mendekripsi tiket menggunakan kunci rahasianya sendiri untuk mengambil Kunci Sesi Klien/Server. Dengan menggunakan kunci sesi, SS mendekripsi Authenticator dan mengirimkan pesan berikut ke klien untuk mengkonfirmasi identitas aslinya dan kesediaannya untuk melayani klien:
• Pesan H: cap waktu yang ditemukan di Authenticator klien ditambah 1, dienkripsi menggunakan Kunci Sesi Klien/Server.
3. Klien mendekripsi konfirmasi menggunakan Kunci Sesi Klien/Server dan memeriksa apakah timestamp diperbarui dengan benar. Jika demikian, maka klien dapat mempercayai server dan dapat mulai mengeluarkan permintaan layanan ke server.
4. Server menyediakan layanan yang diminta kepada klien.

• Titik kegagalan tunggal: Hal ini memerlukan ketersediaan server pusat secara terus-menerus. Ketika server Kerberos mati, tidak ada seorang pun yang bisa log masuk. Hal ini bisa diatasi dengan menggunakan beberapa server Kerberos dan mekanisme otentikasi darurat.
• Kerberos memerlukan jam dari semua host yang terlibat untuk disinkronkan. Tiket memiliki periode ketersediaan waktu dan jika jam host tidak disinkronkan dengan jam server Kerberos, otentikasi akan gagal. Konfigurasi default mensyaratkan bahwa waktu jam tidak lebih dari 10 menit terpisah. Dalam prakteknya Network Time Protocol (NTP) biasanya digunakan untuk menjaga agar semua host tersinkronisasi.
• Protokol administrasi tidak terstandardisasi dan berbeda di antara implementasi server. Perubahan kata sandi dijelaskan dalam RFC 3244.
• Karena kunci rahasia untuk semua pengguna disimpan pada server pusat, kompromi server itu akan mengkompromikan semua kunci rahasia pengguna.
• Klien yang dikompromikan akan membahayakan kata sandi pengguna.

• Manajemen identitas
• Protokol kata sandi jarak jauh yang aman (SRP)
• Antarmuka Program Aplikasi Layanan Keamanan Generik (GSS-API)