Kerberos (protokol)

Tarihçe ve gelişim

MIT, Athena Projesi tarafından sağlanan ağ hizmetlerini korumak için Kerberos'u geliştirmiştir. Protokol adını Yunan mitolojisinde Hades'in üç başlı korkunç bekçi köpeği olarak bilinen Yunan mitolojik karakteri Kerberos'tan (veya Cerberus) almıştır. Protokolün çeşitli versiyonları mevcuttur; 1-3 versiyonları sadece MIT'de dahili olarak kullanılmaktadır.

Kerberos sürüm 4'ün (56 bitlik anahtarlarla DES şifreleme algoritmasını kullanan) başlıca tasarımcıları olan Steve Miller ve Clifford Neuman, bu sürümü 1989 yılında yayınladılar, ancak öncelikle Athena Projesi için hedeflemişlerdi.

John Kohl ve Clifford Neuman tarafından tasarlanan Sürüm 5, Sürüm 4'ün sınırlamalarını ve güvenlik sorunlarını aşmak amacıyla 1993 yılında RFC 1510 olarak ortaya çıktı (2005 yılında RFC 4120 tarafından geçersiz kılındı). MIT, Kerberos Sürüm 5'in bir uygulamasını BSD lisansı tarafından kullanılana benzer bir yazılım lisansı altında ücretsiz olarak kullanıma sunmaktadır.

Birçok şirket Kerberos Sürüm 5'i ticari yazılımlarda kullanmıştır:

·         Microsoft'un Windows 2000 ve sonraki sürümleri varsayılan kimlik doğrulama yöntemi olarak Kerberos'u kullanır. Kerberos protokol paketine yapılan
bazı Microsoft eklemeleri RFC 3244 "Microsoft Windows 2000 Kerberos Şifre Değiştirme ve Şifre Belirleme Protokolleri "nde belgelenmiştir.
RFC 4757, Microsoft'un RC4 şifresini
 kullandığını belgelemektedir. Microsoft Kerberos protokolünü kullan
ırken MIT yazılımını kullanmaz[1].

·         Apple'ın Mac OS X'i de hem istemci hem de sunucu sürümlerinde Kerberos kullanmaktadır.

·         Red Hat Linux sürüm 4 ve sonrası hem istemci hem de sunucu sürümlerinde Kerberos kullanır.

2005 yılında, IETF Kerberos çalışma grubu Kerberos Sürüm 5 [2] için yeni güncellenmiş spesifikasyonları tanıttı. güncellemeler şunları içerir:

·         "Şifreleme ve Checksum Spesifikasyonları" (RFC 3961),

·         "Kerberos 5 için Gelişmiş Şifreleme Standardı (AES) Şifrelemesi" (RFC 3962),

·         Kerberos Sürüm 5 spesifikasyonunun yeni bir baskısı "Kerberos Ağ Kimlik Doğrulama Hizmeti (V5)" (RFC 4120). Bu sürüm RFC 1510'u yürürlükten kaldırır, protokolün yönlerini ve kullanım amacını daha ayrıntılı ve net bir şekilde açıklar,

·         GSS-API spesifikasyonunun yeni bir baskısı "Kerberos Sürüm 5 Genel Güvenlik Hizmeti Uygulama Programı Arayüzü (GSS-API) Mekanizması: Sürüm 2." (RFC 4121).

2007 yılında MIT, gelişimin devamı için Kerberos Konsorsiyumu'nu kurdu.

Protokol

Kerberos temel olarak Needham-Schroeder protokolünü kullanır. Mantıksal olarak iki ayrı bölümden oluşan "anahtar dağıtım merkezi (KDC)" olarak bilinen güvenilir bir üçüncü taraf kimlik doğrulamasından yararlanır: bir Kimlik Doğrulama Sunucusu (AS) ve bir Bilet Verme Sunucusu (TGS). Kerberos, kullanıcıların kimliğini kanıtlamaya yarayan "biletler" (Kerberos biletleri olarak adlandırılır) temelinde çalışır.

Kerberos veritabanı: Anahtar dağıtım merkezi (KDC) gizli anahtarlardan oluşan bir veritabanı tutar; ağdaki her varlık - ister istemci ister sunucu olsun - yalnızca kendisinin ve KDC'nin bildiği bir gizli anahtarı paylaşır. Bu anahtarın bilinmesi her bir varlığın kimliğini kanıtlamaya yarar. İki varlık arasındaki iletişim için KDC, iletişimlerini güvence altına almak için kullanabilecekleri bir oturum anahtarı oluşturur.

"Kerberos sunucusu" terimi genellikle KDC'yi ifade eder. Güvenilirlik amacıyla, yedek KDC'lere sahip olmak mümkündür. Bunlar "Kerberos bağımlı sunucuları" olarak adlandırılır. Tüm slave sunucular veritabanlarını ana Kerberos sunucusundan senkronize eder.

"Kerberleştirilmiş uygulama sunucusu" terimi genellikle istemcilerin kimlik doğrulama için Kerberos biletleri kullanarak iletişim kurduğu Kerberleştirilmiş programları ifade eder. Örneğin, Kerberos telnet sunucusu Kerberleştirilmiş uygulama sunucusuna bir örnektir . "Kerberleştirilmiş uygulamalar" terimi Kerberleştirilmiş uygulama sunucusunun istemci tarafına atıfta bulunmak için kullanılırken, örneğin Kerberos telnet istemcisi Kerberleştirilmiş uygulamalara bir örnektir

Protokolün güvenliği büyük ölçüde şunlara bağlıdır:

1. Katılımcılar gevşek senkronize zamanı korurlar.
2. Kısa ömürlü bir orijinallik beyanı: Kerberos biletleri.

Protokolün basitleştirilmiş açıklaması

Aşağıdaki kısaltmalar kullanılacaktır:

·         AS = Kimlik Doğrulama Sunucusu

·         TGS = Bilet Verme Sunucusu

·         SS veya Sunucu = Hizmet Sunucusu (Yazdırma sunucusu, dosya sunucusu vb. gibi hizmet talep eden sunucu kullanıcısı)

·         TGT = Ticket Granting Ticket (TGS için Kerberos bileti. AS tarafından hazırlanır, daha sonra TGS ile konuşmak için kullanılır).

Kısaca, istemci uzun vadeli bir paylaşılan sır kullanarak AS'ye kimlik doğrulaması yapar ve AS'den bir bilet alır. Daha sonra istemci aynı paylaşılan sırrı kullanarak SS için ek bilet almak üzere bu bileti kullanabilir. Bu biletler SS'ye kimlik doğrulamasını kanıtlamak için kullanılabilir.

Daha ayrıntılı olarak protokol

Kullanıcı İstemcisi Tabanlı Oturum Açma Adımları:

1. Kullanıcı, istemci makineye bir kullanıcı adı ve parola girer.
2. İstemci, girilen parola üzerinde tek yönlü bir işlev (çoğunlukla bir Hash işlevi) gerçekleştirir ve bu, istemci/kullanıcının gizli anahtarı haline gelir.

İstemci Kimlik Doğrulama Adımları:

1. İstemci, AS'ye kullanıcı adına hizmet talep eden bir açık metin mesajı gönderir.
   Örnek mesaj: "Kullanıcı XYZ hizmet talep etmek istiyor".
   Not: AS'ye ne gizli anahtar ne de parola gönderilir.
2. AS, istemcinin kendi veritabanında olup olmadığını kontrol eder. Eğer öyleyse, AS aşağıdaki iki mesajı istemciye geri gönderir:
• Mesaj A: İstemci/kullanıcının gizli anahtarı kullanılarak şifrelenmiş İstemci/TGS Oturum Anahtarı.
• Mesaj B: TGS'nin gizli anahtarı kullanılarak şifrelenmiş TGT (istemci kimliği, istemci ağ adresi, bilet geçerlilik süresi ve İstemci/TGS Oturum Anahtarını içerir).
3. İstemci A ve B mesajlarını aldıktan sonra, İstemci/TGS Oturum Anahtarını elde etmek için A mesajının şifresini çözer. Bu oturum anahtarı TGS ile daha sonraki iletişimler için kullanılır. Bu noktada, istemci kendisini TGS'ye doğrulamak için yeterli bilgiye sahiptir.
   Not: İstemci, TGS'nin gizli anahtarı kullanılarak şifrelendiği için B mesajının şifresini çözemez.

Müşteri Hizmetleri Yetkilendirme Adımları:

1. Hizmet talep ederken, istemci TGS'ye aşağıdaki iki mesajı gönderir:
• Mesaj C: Mesaj B'deki TGT ve talep edilen hizmetin ID'sinden oluşur.
• Mesaj D: Kimlik Doğrulayıcı (istemci kimliği ve zaman damgasından oluşur), İstemci/TGS Oturum Anahtarı kullanılarak şifrelenir.
2. C ve D mesajlarını aldıktan sonra, TGS C mesajından B mesajını alır ve TGS gizli anahtarını kullanarak B mesajının şifresini çözer. Bu ona Müşteri/TGS Oturum Anahtarını verir. TGS bu anahtarı kullanarak D mesajının (Doğrulayıcı) şifresini çözer ve istemciye aşağıdaki iki mesajı gönderir:
• Mesaj E: SS gizli anahtarı kullanılarak şifrelenmiş İstemci-Sunucu bileti (istemci kimliği, istemci ağ adresi, geçerlilik süresi ve İstemci/Sunucu Oturum Anahtarını içerir).
• Mesaj F: İstemci/Sunucu Oturum Anahtarı, İstemci/TGS Oturum Anahtarı ile şifrelenmiştir.

Müşteri Hizmet Talebi Adımları:

1. TGS'den E ve F mesajlarını alan istemci, SS'ye kimlik doğrulaması yapmak için yeterli bilgiye sahip olur. İstemci SS'ye bağlanır ve aşağıdaki iki mesajı gönderir:
• Mesaj E: önceki adımdan (SS gizli anahtarı kullanılarak şifrelenmiş İstemci-Sunucu bileti).
• Mesaj G: istemci kimliğini, zaman damgasını içeren ve İstemci/Sunucu Oturum Anahtarı kullanılarak şifrelenen yeni bir Kimlik Doğrulayıcı.
2. SS, İstemci/Sunucu Oturum Anahtarını almak için kendi gizli anahtarını kullanarak biletin şifresini çözer. Oturum anahtarını kullanarak, SS Kimlik Doğrulayıcının şifresini çözer ve gerçek kimliğini ve müşteriye hizmet verme isteğini onaylamak için müşteriye aşağıdaki mesajı gönderir:
• Mesaj H: İstemcinin Kimlik Doğrulayıcısında bulunan zaman damgası artı 1, İstemci/Sunucu Oturum Anahtarı kullanılarak şifrelenmiştir.
3. İstemci, İstemci/Sunucu Oturum Anahtarını kullanarak onayın şifresini çözer ve zaman damgasının doğru şekilde güncellenip güncellenmediğini kontrol eder. Eğer öyleyse, istemci sunucuya güvenebilir ve sunucuya hizmet istekleri göndermeye başlayabilir.
4. Sunucu, talep edilen hizmetleri istemciye sağlar.

Dezavantajlar

• Tek hata noktası: Merkezi bir sunucunun sürekli kullanılabilirliğini gerektirir. Kerberos sunucusu çalışmadığında kimse oturum açamaz. Bu, birden fazla Kerberos sunucusu ve acil durum kimlik doğrulama mekanizmaları kullanılarak çözülebilir.
• Kerberos, ilgili tüm ana bilgisayarların saatlerinin senkronize edilmesini gerektirir. Biletlerin bir zaman kullanılabilirlik süresi vardır ve ana bilgisayar saati Kerberos sunucu saatiyle senkronize edilmezse kimlik doğrulama başarısız olur. Varsayılan yapılandırma, saatlerin en fazla 10 dakika aralıklı olmasını gerektirir. Uygulamada, tüm ana bilgisayarları senkronize tutmak için genellikle Ağ Zaman Protokolü (NTP) kullanılır.
• Yönetim protokolü standartlaştırılmamıştır ve sunucu uygulamaları arasında farklılık gösterir. Parola değişiklikleri RFC 3244'te açıklanmıştır.
• Tüm kullanıcıların gizli anahtarları merkezi sunucuda saklandığından, bu sunucunun ele geçirilmesi tüm kullanıcıların gizli anahtarlarını tehlikeye atacaktır.
• Güvenliği ihlal edilmiş bir istemci, kullanıcının parolasını tehlikeye atacaktır.

İlgili sayfalar

• Kimlik yönetimi
• Güvenli uzaktan parola protokolü (SRP)
• Genel Güvenlik Hizmetleri Uygulama Programı Arayüzü (GSS-API)