Kerberos

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ı.