KERBEROS

The name Kerberos comes from Greek mythology; it is the
three-headed dog that guarded the entrance to Hades

Not: Bu dokumanda Kerberos IV anlatlmaktadr. Kerberos V ile farkllklar yaznn
sonunda verilen linkte açklanmaktadr
1) Giriş
Ağ teknolojilerinin yaygınlaşmasından önce, işlem gücü yüksek olan tek bir
time-sharing sisteme bir çok dummy terminalin takılmasıyla çalışma ortamları
oluşturulurdu. Ana bilgisayara bağlanmış her kullanıcı kendi sırasını beklemek
zorundaydı. Bu ortamlarda, güvenlik önlemlerinin alınmasına gerek duyulmuyordu,
çünkü sadece bir tane bilgisayar vardı, herkes dummy terminaller ile bu ana
bilgisayara bağlanıp, ana bilgisayar üzerindeki uygulamayı çalıştırıp, kendine
ait dosyalara ulaşabiliyordu.


Ağ teknolojilerinin çıkması ve yaygınlaşması ile, günümüzde artık her
kullanıcının önünde workstation denen bilgisayarlar var. Kullanıcıların hepsi
birbirine bağlıdır ve birçok işini merkezi sunucular yardımıyla hallederler.
Kullanıcıların kişisel dosyalarının tutulduğu dosya sunucuları, kullanıcıların
çıktı almasına yarayan yazıcı sunucuları, kullanıcıların bilgisayarlarında
yazılımların çalışmasını sağlayan terminal sunucuları bunlara örnek olarak
verilebilir.

Bu durum, birçok güvenlik ihtiyacını beraberinde getirmiştir. Kötü niyetli,
saldırgan kişiler, merkezi sunucularda bulunan başka kullanıcılara ait
kaynakları kullanabilirler. Bunun için, hattı dinlemeleri ve kullanıcı
şifrelerini ele geçirmeleri ya da kendilerini başka bir kullanıcı gibi
göstermeleri gerekir ki bu gibi saldırılar çok basittir. Öyleyse, ağ
teknolojilerinin çok geliştiği ve hızla gelişmesiyle devam ettiği günümüzde
güvenlik önlemlerine ihtiyaç olacaktır.

Bu amaçla, birçok güvenlik konseptleri ve bunları karşılayacak yazılımlar
geliştirilmiştir. Kerberos da bunlarda biridir. Kerberos, MIT tarafından 1983
senesinde geliştirilen, temeli ağ üzerinde kimlik doğrulaması ve kriptoloji
olan bir güvenlik protokolüdür.

MIT üniversitesinde, öğrenciler, ağ paketlerini dinleyerek kullanıcı
şifrelerini ele geçiriyorlardır. Bunun yanında, kendilerini başkaları gibi
gösterip birçok önemli bilgisayara erişim hakkı kazanıyorlardı. Bunların önüne
geçmek amacıyla, MIT kerberosu çıkardı.

Kerberos, kendi içerisinde birçok güvenlik konseptini barındırır. Bu haliyle aslında
karışık bir güvenlik mekanizmasıdır. Bu dokümanda, kerberosun tüm güvenlik
konseptlerini bir anda anlatılmamıştır.

Bunun yerine, hiçbir güvenlik önlemi olmayan bir ağdan başlanarak (örneğin
kerberostan önceki MIT ağı) aşama aşama kerberoslu ağ yapısına ulaşılmıştır.

2) Adım Adım Kerberos
Örneğin, bir kullanıcı mail sunucudaki maillerine bakmak istiyor. Bunun için
kendi çalışma bilgisayarındaki mail istemci programını kullanacaktır. İstemci
program kullanıcının yerine mail sunucuya bağlanacak ve kullanıcın maillerini
alacaktır. Mail istemci türü programlara CLIENT diyoruz. Bu durumda, CLIENT
programı, kullanıcının kimliğini ispat etmek zorundadır. Daha ayrıntılı
söylenirse, kullanıcının iddiasının doğru olduğunu bildirmek zorundadır.
Kullanıcının iddiası, kullanıcı ismidir (login). Örneğin kullanıcı ben ‘kara'
kullanıcıyım dediği zaman, bu iddiasının doğruluğu kullanıcı şifresi ile
anlaşılır. Öyleyse, her sunucuda kullanıcı bilgilerinin (login ve şifre) olduğu
bir veritabanı olmalıdır. CLIENT programı kullanıcının yerine mailleri
sunucudan çekmek için, kullanıcı bilgilerini (login ve şifre) sunucuya
götürecek, sunucu da CLIENT programının getirdiği bilgileri kendi
veritabanındaki bilgiler ile karşılaştırıp sonuç positif olursa, mailleri
okumaya açacaktır.

Bu durumda bir takım sakıncalar ortaya çıkacaktır. Sistemde bulunan her
sunucunun kendine ait bir veritabanı olacaktır. Bir kullanıcı şifresini
değiştireceği zaman her sunucuya tek tek bağlanıp her servis için şifresini
değiştirmek zorundadır. Ayrıca şifreler clear text gitmektedir.

Bu durumu aşmak için yeni bir konsept gereklidir. O da şudur. Sadece
kullanıcıların şifresi yoktur. Kullanıcılarla beraber, servislerin de şifresi
olmalıdır. Her kullanıcı kendi şifresini bildiği gibi her servis programı da
kendi şifresini bilir. Servis programlarına örnekler, mail, print, telnet
sayılabilir. Bütün bu servislerin üstünde, AUTHENTICATION SERVICE vardır.
AUTHENTICATION SERVICE bütün kullanıcı ve servis şifrelerini bilir.
AUTHENTICATION SERVICE, bu şifreleri merkezi, tek bir sunucuda tutar.

Bir kullanıcı, mail servisini kullanmak istediği zaman (örneğin yeni maillerine
bakacak), kullanıcı direk olarak mail sunucuya bağlanamaz. Kullanıcı,
AUTHENTICATION SERVICE'e kendi kimliğini doğrulatmadan maillerine bakamayacaktır.
AUTHENTICATION SERVICE, kullanıcıdan kimliğini ispat etmesini ister. Kullanıcı
bu amaçla ismini ve şifresini AUTHENTICATION SERVICE'e yollar. AUTHENTICATION
SERVICE kendi veritabanındaki kullanıcı ismi ve şifresi ile kullanıcıdan gelen
isim ve şifreyi karşılaştırır. Kullanıcı, AUTHENTICATION SERVICE'e kimliğini
ispat ettikten sonra, AUTHENTICATION SERVICE, kullanıcının kullanmak istediği
mail sunucuyu hizmete açmalıdır (kullanıcıya kefil olmalı). Bunu yapmanın bir
yolu, AUTHENTICATION SERVICE'nin, mail servisinin şifresini CLIENT programına
vermesidir. Böylece, CLIENT programı, mail sunucuya, sunucunun şifresini
gönderek, kendisinin AUTHENTICATION SERVICE tarafında doğrulandığını ispat
edebilir. Ama burada bir problem vardır. AUTHENTICATION SERVICE direk olarak
şifrenin kendisini vermemelidir. Bu durum, bir çok güvenlik açığını beraberinde
getirecektir.

Bunun yerine, AUTHENTICATION SERVICE kullanıcıya bir TICKET verir. Bu bilet
mail servisinin şifresi ile enkript edilmiş kullanıcı ismini barındırır.

Kullanıcı, ismini ve bileti, mail sunucuya yollar. Mail sunucudaki servis,
kendi şifresini kullanarak, bileti dekript eder. Bilet doğru olarak çözülürse,
biletten, AUTHENTICATION SERVICE'nin koyduğu kullanıcı ismi çıkar. Son aşamada
ise, mail servisi, kullanıcının gönderdiği isim ile biletten çıkan isme bakar,
aynı ise, hizmet vermeye başlar.

Anti parantez söylemek gerekirse, kullanıcı, AUTHENTICATION SERVICE'e en baştan
hangi servisi kullanmak istediğini belirtmek zorundadır ki, kullanıcı AUTHENTICATION
SERVICE'e kendini ispatladıktan sonra, AUTHENTICATION SERVICE kullanıcı yerine
işleri halledebilsin, örneğin uygun bileti hazırlasın.

Bu biletin içerisinde, kullanıcı ismi ile beraber, servis ismi de bulunur.
Servis ismini de tıpkı kullanıcı ismi gibi AUTHENTICATION SERVICE koyar. Servis
isminin amacı ekstra güvenliktir. Herhangi bir servis bileti çözdüğü zaman,
içerisinde kullanıcı ismi ile beraber kendi isminin olup olmadığına bakar.

Güvenliği daha da artırmak için, bu biletin içine CLIENT programının çalıştığı
bilgisayarın network adresi de konmalıdır. Eğer konmaz ise, ağda sniff
yapılarak bir bilet yakalanabilir. Daha sonra, CLIENT programında değişiklik
yapılarak, saldırganın çalışma bilgisayarı kurban kullanıcıya aitmiş gibi
gösterilebilir. En sonunda, saldırganın CLIENT programı sniff edilmiş bileti
sunucuya gönderir. Sunucu, bileti açar, içindeki kullanıcı ismini, CLIENT
programının söylediği isimle karşılaştırır. Doğru olduğu anda, kurban
kullanıcının maillerine ulaşılabilir.

Biletin içine network adresi konduğu zaman, durum şöyle olacaktır. Saldırgan
bileti sniff ederek alır. CLIENT programında değişiklik yaparak (kullanıcı
ismini değiştirerek), bileti sunucuya yollar. Sunucu, bileti açar, içinden
çıkan kullanıcı ismini ve network adresini gönderen makineninkilerle
karşılaştırır. Kullanıcı isimleri tutar. Çünkü, CLIENT programında saldırgan
tarafından değişiklik yapılmıştır. Ancak network adresleri tutmayacaktır.
Biletin çalıntı olduğu anlaşılacak ve mail servisi oturumu kesecektir.

Bir kullanıcının bir servisi kullanması için AUTHENTICATION SERVICE tarafından
çıkarılan bilet her defasında tekrar çıkarılmaz. Client programı, sunucudan
tekrar mail bakmak istediği zaman, daha önce çıkmış olan bileti sunucuya direk
yollar. (COPY)

Kullanıcının daha önce kullanmadığı bir servisi ilk defa kullanacağı zaman,
AUTHENTICATION SERVICE'e gitmesi gerekir. Örneğin, kullanıcı maillerine baktı
ve mailin birini print etmek istiyor. O zaman, print sunucuyla kontağa geçmeden
önce, AUTHENTICATION SERVICE'ten bilet almalıdır. Aslında, bu aşamada önemli
bir güvenlik açığı mevcuttur. Çünkü, istemci program, bilet almak için, ismini
ve şifresini ağ üstünden clear text yollamaktadır.

İki önemli güvenlik açığı tekrar söylenirse, kullanıcı her yeni servis için
şifresini AUTHENTICATION SERVICE'e yollamak zorundadır ve kullanıcı şifresi
AUTHENTICATION SERVICE ‘e ağ üzerinde clear text gitmektedir.

İlk problem yeni bir servisin çalıştırılması ile düzeltilebilir. Bu servisin
adı TICKET-GRANTING SERVICE'dir. Bu servisin başlatılmasıyla, clear text şifre
sadece bir defa gidecektir (ilerde anlatılacak). Yani, kullanıcın kullanmak
istediği her yeni servis için tek tek AUTHENTICATION SERVICE'e gitmesi
önlenecektir.

Ticket-granting servis, AUTHENTICATION SERVICE'nin üreteceği biletleri üretir.
Ticket-granting servisinin, bir kullanıcı için bilet üretmeden önce, kullanının
en başta kendisini, AUTHENTICATION SERVICE'e ispatlaması gerekir. Zaten tek
clear text şifre bu aşamada (yani en başta) gitmektedir. Kullanıcı kendini
AUTHENTICATION SERVICE'e ispatladıktan sonra, AUTHENTICATION SERVICE,
kullanıcıya özel bir bilet yollar. Bu bilet, TICKET-GRANTING TICKETtir.

TICKET-GRANTING SERVICE aslında AUTHENTICATION SERVICE'nin bir parçasıdır.
AUTHENTICATION SERVICE'nin şifre veritabanına ulaşmak zorundadır. Çünkü,
değişik servisler için bilet çıkaracağı zaman, o servisin şifresi ile,
kullanıcı ismini, bilgisayarın network adresini ve servis ismini şifrelemek
zorundadır. O halde bu iki servis aynı makinede çalışır. Kullanıcı, kullanacağı
her yeni servis için AUTHENTICATION SERVICE'e ağdan şifresini yollayacağına,
ticket-granting ticket'i TICKET-GRANTING SERVICE'e yollar.

Ayrıntısı yazılırsa, kullanıcı, çalışma bilgisayarının başına geçer ve kinit
isminde bir program çalışır. Bu program AUTHENTICATION SERVICE'le kontağa
geçer. Kullanıcıyı, AUTHENTICATION SERVICE'e ispatlar. Sonra da, kinit programı
kullanıcıya bir ticket-granting ticket yollar. Kullanıcı, maillerine bakmak
istediği zaman, (kullanıcının elinde henüz mail servisi için bilet yok)
ticket-granting ticket kullanılır. Bu özel bilet ile mail sunucunun bileti
alınır. Dikkat edilirse, mail sunucu biletini almak için, kullanıcı şifresini
yollamamıştır.

Ticket-granting ticket defalarca kullanılabilir. Kullanıcının kullanmak
istediği her bir servis için ticket granting servis çıkarılmaz. Aynı şekilde,
ticket-granting servisinin sağladığı diğer servis biletleri de defalarca
kullanılır.

İkinci problem ise, şöyle çözülür. kinit programı, AUTHENTICATION SERVICE'den
ticket-granting ticket alacağı zaman, clear text kullanıcı şifresini yollamaz.
Bunun yerine sadece kullanıcı ismini yollar. AUTHENTICATION SERVICE,
ticket-granting ticket'in bulunduğu bir paket hazırlar. Bunu göndermeden önce
de, kullanıcının şifresi ile enkript eder. (AUTHENTICATION SERVICE'nin
veritabanında tüm kullanıcı ve servis şifreleri tutuluyordu). Kinit programını
gönderen çalışma bilgisayarına bu paket gelir ve kinit programı kullanıcının
girdiği şifre ile bu paketi dekript eder. Böylece ticket-granting ticket'i
güvenli bir yolla elde etmiş oluruz. Artık, bu özel bilet ile her servise
ulaşabiliriz.

Bu noktada, bazı güvenlik açıklıları hala mevcuttur. Biletlerin tekrar
kullanılabiliyor olması, sistem performansını fazlasıyla artıracaktır ancak,
aslında güvenliği azaltan bir noktadır. Örneğin bir kullanıcı bilgisayarına
girdikten sonra, mail, print ve dosya sunucuları ile işler yaptı. Bu
işlemlerden sonra, servislerin biletleri bilgisayarda kalacaktır. Eğer,
kullanıcı bu biletleri silmeden bilgisayarını terk ederse, biletleri
çalınabilecek ve bu biletler tekrar tekrar kullanılabildiği için, sonsuza kadar
işe yarayacaktır.

Bunun gibi tehlikeli durumların önlenmesi basit bir operasyon ile sağlanabilir.
Kullanıcı bilgisayardan her çıktığında, küçük bir program, bilgisayarda bulunan
biletleri silebilir.

Ancak bu, sadece çok basit bir güvenlik açığını önlemiştir.

İşin daha kötüsü ise, bu biletlerin, bulunduğu bilgisayarda kullanılma
zorunluluğu olmamasıdır. Bunun önlenmesi için, biletlerde çalışma
bilgisayarının network adresi bulunuyordu. Ancak bu güvenlik önleminin önüne
geçilmesi çok kolaydır. (IP Spoofing)

Ağ trafiği sniff edilerek, birçok servis ve kullanıcı için kullanıcı biletleri
(şifrelenmiş halleri) ele geçirilebilir. Kullanıcının, sunucu ile kurduğu oturumun
bitmesi beklenir, oturumun bittiğine inanıldığı zamanda ise, sniff edilen
biletlerdeki şifrelenmiş bilgiler tahmin edilir. Bu tahminin sonucunda, CLIENT
programında, kullanıcı tarafından değişiklik yapılır (isim değişikliği).
Saldırgan, kendi bilgisayarının ağ yazılımında değişiklik yaparak, bilgisayarın
ağ adaptöründen çıkan paketlerin, biletin içinde bulunduğunu tahmin ettiği
network adresinden çıktığını gösterebilir (spoofing). Bu tip ataklar replay
ataklarıdır.

Bu durumun önüne geçilmesi için, biletlerin kullanım süresi ve kullanım sayısı
belirlenmelidir. O zaman biletin içerisinde, kullanıcı ismi, bilgisayarın
network adresi, servis isminin yanında, kullanım süresi (lifespan) ve kullanım
sayısı (timestamp) bulunmalıdır.

Aslında bu da probleme kalıcı bir çözüm getirmeyecektir. Çünkü, kullanım süresi
ve kullanım sayısını aşmadan, saldırganlar hala bu biletleri kullanabilirler.
Bu iki kısmın eklenmesi, güvenliği çok az artırmıştır.

Şimdiye kadar özetlersek,

Sunucularda, kullanıcıların kimlik doğrulamasında, sırası ile aşağıdaki testler
yapılmaktadır.

Servis bileti dekript edebildi mi?
Biletin süresi geçmiş mi?
Biletteki isim ve network adresleri ile kullanıcıdan gelen aynı bilgiler
tutuyor mu?
Bu testler sırasıyla şunları sağlar.

Biletin geçerli bir AUTHENTICATION SERVICE makinesinden geldiğini ispatlar.
Eski biletlerin kullanılması önlenir. Eski biletler büyük ihtimalle çalıntıdır.
(sniff edilmiş)
Bu da aynı şekilde, çalıntı biletlere karşı koruyucu bir önlemdir.
Saldırganlar, kolaylıkla bütün bunları sağlayabilir ve replay atakları ile
kullanıcı bilgilerine ulaşabilir. Bunun nedeni, sunuculardaki servislerin,
bileti gönderenin gerçekten o biletin gerçek sahibi olduğunu bilememesidir.

O halde servis ile istemci ortak bir şey saklamalıdır. Bu amaçla,
AUTHENTICATION SERVICE, bir tane kullanıcı bilgisayarına bir tane de servis
bilgisayarına (örneğin mail sunucu) SESSION KEY vermelidir. Bu oturum
anahtarları kullanılarak, sunucu bilgisayar, bileti gönderenin doğru istemci
bilgisayar olduğunu anlayabilir.

AUTHENTICATION SERVICE, istemci bilgisayarına vereceği oturum anahtarını
hazırladığı biletin yanında gönderir. Servis bilgisayarı ise, oturum
anahtarını, istemci bilgisayardan gelen bilet (istemci bilgisayara da
AUTHENTICATION SERVICE vermişti) ile birlikte alır. Yani biletin içine yeni bir
bilgi eklenmiştir.

TICKET - {oturum anahtarı : kullanıcı ismi : network adresi : servis ismi :
kullanım süresi : kullanım sayısı}

Kullanıcı, bir sunucuya ulaşmak istediği zaman, istemci makinesi AUTHENTICATION
SERVICE ile işini bitirdikten sonra, AUTHENTICATOR denen bir paket üretir.
AUTHENTICATOR, kullanıcı ismi ve çalışma bilgisayarının network adresini
bulundurur. İstemci, AUTHENTICATOR paketini oturum anahtarı ile şifreler ve
sunucuya, bilet ile beraber yollar. Sunucu ilk aşamada, AUTHENTICATOR paketini
dekript edemez. Çünkü çözmek için gerekli oturum anahtarı yoktur. Oturum
anahtarı biletin içerisindedir. Öyleyse öncelikle bileti, sunucu kendi şifresi
ile dekript eder. Sonucunda, sunucudaki servis aşağıdaki bilgileri elde eder.

Biletin kullanım süresi ve sayısı
Biletin gönderen kullanıcı ismi
Biletin gönderen bilgisayarın network adresi
Oturum anahtarı
Servis öncelikle, biletin süresine bakar. Süresi dolmamış ise, oturum
anahtarını kullanarak, AUTHENTICATOR paketini dekript eder. Eğer sorun çıkmaz
ise, sonuç kullanıcı ismi ve bilgisayarın network adresi olacaktır. Servis, bu
bilgileri, biletin içindeki bilgilerle ve bilet ile AUTHENTICATOR paketini
yollayan istemcinin bilgileriyle karşılaştırır. 3 kaynaktan gelen bu bilgiler
aynı ise bileti gönderenin, biletin gerçek sahibi olduğu anlaşılmış olur.

Ancak burada da yine bir problem vardır. AUTHENTICATOR ve bilet birlikte
gönderilmektedir. Paketlerin ikisi birden sniff edilerek biletin süresi
geçmediği sürece kullanılabilir. Bunun için eskiden olduğu gibi kullanıcı
ismini ve saldırgan bilgisayarın network adresini değiştirmek yeterlidir.

Buna basit bir çözüm bulunabilir. AUTHENTICATOR paketinin sadece bir defa
kullanılabilmesi basit ve güzel bir çözümdür. Örneğin, mail sunudan maillerini
almak isteyen istemci hem AUTHENTICATOR paketini hem de bileti ağ üzerinde
yollayacaktır. Bu arada saldırgan her iki paketi de alacaktır. Ancak, saldırgan
paketi alıp replay saldırısı yapıncaya kadar, sunucu AUTHENTICATOR paketi
üzerinde işlemlerini yapıp bitireceğinden, replay saldırısı yapılamayacaktır.
Çünkü aynı AUTHENTICATOR paketi sadece bir kere kullanılabilecektir.

Öyleyse, AUTHENTICATOR paketine kullanım süresi ve kullanım sayısı bölümleri
eklenebilir. Kullanım süresi dakikalarla ölçülen bir süre olur. İstemci,
AUTHENTICATOR paketini üretirken, o anki zamanı paketin içerisine koyar ve
sunucuya yollar. Sunucu bu paketi alır ve sonunda AUTHENTICATOR paketini
dekript eder. AUTHENTICATOR'ün kullanım süresi ve sayısı kısımlarına bakar.
AUTHENTICATOR'ün süresi geçmedi ise kimlik doğrulama gerçekleşir. Bu durumda,
saldırganın bileti ve AUTHENTICATOR paketini hattan alması, kullanıcı ismi ve
network adresini değiştirmesi yeterince uzun bir süreyi alacaktır.

Saldırganın yine başarılı olabileceği düşünülebilir. Şöyle ki: saldırgan,
kullanıcı bilgisayarından (client) sunucuya giden AUTHENTICATOR ve bileti
alacağına, sadece AUTHENTICATION SERVICE'den, istemciye giden paketi
yakalayabilir. Bu pakette, bilet ve oturum anahtarı bulunuyordu. O halde,
saldırgan, bu oturum anahtarını kullanarak, kendi AUTHENTICATOR paketlerini
üretebilir.

Aslında durum sanıldığı gibi değildir. Olan işler en baştan sırasıyla izlenirse
bunun imkansız olduğu anlaşılır.

Kullanıcı çalışma bilgisayarının başına oturduğu zaman kinit programı çalışır.
Kinit programı ticket-granting ticket'i alabilmek için AUTHENTICATOR SERVICE'e
kullanıcı ismini yollar. AUTHENTICATOR SERVICE, ticket-granting ticket'i
hazırlamaya başlar. Bu biletin içerisine konacak olan oturum anahtarını da
hazırlar. Bu anahtarın bir kopyasına biletin içine koyar ve bu bileti
ticket-granting servisin şifresi işe enkript eder. Diğer oturum anahtarı
kopyasını da bu hazırlanmış biletin yanına koyar. Çalışma bilgisayarına göndermeden
önce, kinit programından hangi kullanıcı ismi ile istek geldiyse, o
kullanıcının şifresi ile paketi şifreleyip yollar. Sonuç olarak, saldırgan,
oturum anahtarını sniff etse de zaten kriptolu olacaktır. Sonunda bu paket
istemciye gelir, istemcideki kullanıcı kendi şifresi ile bu paketi dekript
eder. Elinde, ticket-granting ticket ve oturum anahtarı vardır.

Bu aşamadan sonra, kullanıcı maillerine bakmak istedi. Bunun için mail
servisinin bileti gereklidir. Bunun için istemci, ticket-granting ticket'i
kullanarak, ticket-granting servisinden mail sunucu için bir bilet alacaktır.

Bu amaçla istemci, bir AUTHENTICATOR paketi üretir. Bu paket ticket-granting
servisine, mail sunucu bileti vermesi için kullanılacaktır. İstemci, bu paketi
elinde bulunan ticket-granting servisinin oturum anahtarı ile şifreler. İstemci
daha sonra, elinde bulunan ticket granting ticket'i ve AUTHENTICATOR paketini
yollar. (Bunlarla beraber, kullanılmak istenen servisin ismi, kullanıcı ismi ve
bilgisayarın network adresi de gider.) Ticket-granting servisi, bileti kendi
şifresi ile açmaya çalışır. Başarılı olursa, bu biletin içerisindeki oturum
anahtarı ile AUTHENTICATOR paketini açar ve bilgilerin doğru olup olmadığını
kontrol eder. Doğruluğunu anladıktan sonra, kullanıcının mail servisine
ulaşması için, mail servisi bileti hazırlamaya başlar. Bu aşamada mail servisi
için yeni bir oturum anahtarı üretir. Sonra bu bileti, mail servisinin şifresi
ile enkript eder. Daha sonra, şifrelenmiş olan bu biletin yanına, istemci
bilgisayara gidecek olan mail servisi oturum anahtarını koyar ve bu iki paketi,
en başta elde edilen ticket-granting servisinin oturum anahtarı ile şifreler.
Sonra da bu paketi istemciye yollar. Paket şifreli olduğu için, sniff edilde
bile oturum anahtarı elde edilemeyecektir. İstemci kendinde bulunan
ticket-granting servisinin oturum anahtarı ile bu paketi açacaktır. Açtıktan
sonra, AUTHENTICATOR paketi üretmesi için gerekli oturum anahtarı ve bu oturum
anahtarının şifreli bir kopyasının bulunduğu ve mail sunucuya gidecek olan
bilet çıkacaktır.

Görüldüğü gibi aslında problem yoktur.
Ancak son bir problem vardır. İstemciler, sunucular tarafından fazlasıyla
doğrulanmaktadır ancak sunucular, istemci bilgisayarlar tarafından
doğrulanmamaktadır. Örneğin, kullanıcı önemli bir dokümanını print ettirmek
istedi. Bu amaçla uygun bileti edindi, AUTHENTICATOR paketini hazırladı ve
print sunucuya gönderdi. Gönderilen yol üzerindeki saldırgan, bu bilgileri
yönlendirdi, gerçek print sunucuna gelmemesini sağladı. Bu paketleri kendi sunucusuna
gönderdi. Bu sunucu, bileti ya da AUTHENTICATOR paketini çözmeye
çalışmayacaktır, içeriğiyle ilgilenmeyecektir. Bunun yerine, bu paketin geldiği
çalışma bilgisayarına, kimliğinin doğrulandığı söyleyen bir paket yollar.
Böylece, kullanıcının dokümanı saldırganın yazıcısına gider. Öyleyse,
kullanıcıları, saldırgan sunucularından korumak gereklidir. İstemci
bilgisayarın, hassas bilgilerini sunucuya göndermeden önce, sunucunun kimliğini
doğrulaması gerekmektedir. Bu karşılıklı kimlik doğrulamasına, MUTUAL
AUTHENTICATION denmektedir.

Bu tip bir kimlik doğrulama, oturum anahtarları ile kolayca yapılabilir.
Örneğin, kullanıcı AUTHENTICATOR paketini ve bileti print sunucuya yolladır.
Print sunucu yasal ise, biletten oturum anahtarını dekript edecektir. Elde
ettiği oturum anahtarı ile AUTHENTICATOR paketini dekript edecek ve istemcinin
kimlik doğrulamasını başarıyla bitirecektir. Şimdi, sunucunun kendi kimliğini
istemciye ispatlaması aşaması gelmiştir. Bu amaçla, sunucu bir cevap paketi
hazırlar ve bu paketi elde ettiği oturum anahtarı ile şifreler. Bunu istemci
bilgisayara yollar. Oturum anhtarının bir kopyası da istemci de olduğu için,
istemci bu cevapı dekript edebilecek ve mutual authentication tamamlanacaktır.
Artık, istemci, hassas bilgisini yollayabilir.

Sunucu, bir saldırgana ait olsaydı, istemciden gelen bilet ve AUTHENTICATOR
paketine uygun cevabı yollayamayacaktı. Çünkü, elinde valid bir oturum anahtarı
olmayacaktı.

Burada anlatılanlar Kerberos'un içinde bulunan temel güvenlik önlemlerini nedenleri
ile anlatmıştır. ,
http://web.mit.edu/kerberos/www/dialogue.html
adresindeki dialog baz
alınarak yazılmıştır.

Bilge Karabacak
bilge at bilkent.org

__________________________

5
Ortalama: 5 (1 vote)