Βασικές Έννοιες

Το Kerberos σύστημα αναπτύχθηκε από το Massachusetts Institute of Technology (MIT) για να προστατέψει τις δικτυακές υπηρεσίες που παρέχονταν από το Project Athena και βασίζεται στο μοντέλο διανομής κλειδιών (key distribution model) των Needham και Schoeder. Οι εκδόσεις 1 έως 3 χρησιμοποιήθηκαν εσωτερικά από το MIT. Παρ' όλο που σχεδιάσθηκε αρχικά για χρήση με το Project Athena, η 4^η έκδοση πέτυχε παγκόσμια υιοθέτηση. Λόγω, όμως, του γεγονότος ότι πολλά περιβάλλοντα είχαν απαιτήσεις που δεν μπορούσε να καλύψει η 4^η έκδοση, νέα χαρακτηριστικά εισηγήθηκαν με την ανάπτυξη του Κerberos version 5.0 που απευθυνόταν σε περισσότερες περιπτώσεις. Η τρέχουσα έκδοση είναι η 5.0.

Το Kerberos είναι ένα σύστημα πιστοποίησης ταυτότητας το οποίο αναπτύχθηκε με την ελπίδα αντικατάστασης του συστήματος που καλείται πιστοποίηση βάσει ισχυρισμού (authentication by assertion). Η πιστοποίηση βάσει ισχυρισμού στηρίζεται στην εξής αρχή: όταν ο χρήστης τρέχει ένα πρόγραμμα που απαιτεί πρόσβαση σε μία δικτυακή υπηρεσία, το πρόγραμμα ανακοινώνει στον server ότι λειτουργεί εκ μέρους του συγκεκριμένου χρήστη. Ο server πιστεύει τα στοιχεία που του παρέχει ο client (δηλαδή το πρόγραμμα) και εξυπηρετεί τον χρήστη χωρίς να ζητά άλλες αποδείξεις. Όπως καταλαβαίνουμε, η παρεχόμενη ασφάλεια είναι πολύ χαμηλού επιπέδου έως και ανύπαρκτη.

Ένα άλλο σύστημα που χρησιμοποιείται πολύ, είναι η συνοδεία του ονόματος του χρήστη από έναν μυστικό κωδικό. Σε αυτό το εναλλακτικό σχήμα πιστοποίησης ταυτότητας υπάρχουν δύο, τουλάχιστον, διαφορετικά μειονεκτήματα. Πρώτον, αποτελεί χάσιμο χρόνο για τον χρήστη. Δεύτερον και σημαντικότερον, είναι ευάλωτο σε επιθέσεις παθητικού τύπου (passive attacks), καθ' ότι ο κωδικός διανύει τη δίκτυο μη κρυπτογραφημένος. Το σύστημα Kerberos καλύπτει ένα σημαντικό κενό των συστημάτων πιστοποίησης ταυτότητας.

Το Kerberos επιτρέπει στις δικτυακές εφαρμογές να αναγνωρίζουν με ασφάλεια την ταυτότητα του χρήστη που ζητά εξυπηρέτηση, χωρίς να στέλνει στο δίκτυο δεδομένα που μπορούν να επιτρέψουν σε ένα πιθανό εισβολέα να προσποιηθεί ότι είναι ο χρήστης και χωρίς να βασίζεται στις διευθύνσεις των μηχανών του δικτύου. Επίσης, η πιστοποίηση ταυτότητας γίνεται από τον application server και η επικοινωνία γίνεται εν γνώση της πιθανότητας ότι η διακινούμενη πληροφορία μπορεί να τροποποιηθεί και να αναγνωστεί κατά βούληση. Το Kerberos προαιρετικά προσφέρει ακεραιότητα και απόρρητη συναλλαγή για τα δεδομένα που στέλνονται μεταξύ του client και του application server. Σαν application server εννοούμε τον server που προσφέρει υπηρεσίες όπως mail, ftp, http, telnet.

Το σύστημα χρησιμοποιεί μια σειρά από κρυπτογραφημένα μηνύματα για να αποδείξει σε έναν application server ότι ο client λειτουργεί εκ μέρους ενός συγκεκριμένου χρήστη. Για την ανταλλαγή των μηνυμάτων ο Kerberos εκμεταλλεύεται το IP επίπεδο σε συνδυασμό με το UDP πρωτόκολλο. Ο client αποδεικνύει την ταυτότητα του χρήστη παρουσιάζοντας στον application server την απόδειξη – ticket, η οποία περιέχει ένα προσωρινό κλειδί κρυπτογράφησης που θα χρησιμοποιηθεί για την επικοινωνία μεταξύ του application server και του χρήστη, και το πιστοποιητικό – authenticator, το οποίο αποδεικνύει ότι ο client έχει στην κατοχή του το session key που έχει εκδοθεί για τον χρήστη που ορίζεται στο ticket. Οι αποδείξεις εκδίδονται από ένα αφιερωμένο υπολογιστή που καλείται authentication server (AS). Ο authentication server έχει αποθηκευμένα μυστικά κλειδιά, που καλούνται server keys και τα μοιράζεται με τους application servers. Εγκαθίστανται μέσα από κρυπτογραφημένο κανάλι ή με out-of-band επικοινωνία. Το server key πιστοποιεί την αυθεντικότητα των αποδείξεων – tickets που λαμβάνει ο client και ο server. Επιπλέον, ο AS έχει αποθηκευμένα κλειδιά που αναφέρονται σε κάθε χρήστη και καλούνται user keys. Όλα τα κλειδιά εμπεριέχονται σε βάση δεδομένων. Τέλος να πούμε ότι κάθε ticket έχει περιορισμένη διάρκεια ζωής και όταν το χρονικό αυτό διάστημα περάσει τότε είναι άχρηστο. Περαιτέρω ανταλλαγή μηνυμάτων απαιτεί την έκδοση νέου ticket.

Οποτεδήποτε ο χρήστης θέλει να έρθει σε επαφή με κάποιον application server, ο client αναλαμβάνει να ξεκινήσει την διαδικασία απόκτησης κατάλληλων διαπιστευτηρίων (credentials) για τον θα χρησιμοποιηθούν με τον συγκεκριμένο application server. Μια περιληπτική παρουσίαση της συναλλαγής αυτής βλέπουμε παρακάτω:

Ο client επικοινωνεί με τον AS στέλνοντας κατάλληλη αίτηση και αυτός απαντά με τα διαπιστευτήρια. Τα διαπιστευτήρια αποτελούνται από (α) ένα session key που χρησιμοποιείται σαν κλειδί κρυπτογράφησης και (β) ενός ticket για τον application server. Το session key και το ticket διαφέρουν για κάθε application server με τον οποίο επικοινωνεί ο χρήστης. Η αίτηση που στέλνει ο client στον AS καλείται authentication request και περιέχει τα στοιχεία της ταυτότητας του client, το όνομα του application server, την ζητούμενη διάρκεια ζωής του ticket και ένα τυχαίο αριθμό που θα χρησιμοποιηθεί για το ταίριασμα της authentication request με την authentication response. Επίσης, ο client μπορεί να καθορίσει συγκεκριμένες επιλογές σχετικές με την φύση τού ticket (renewable, proxiable, forwardable κτλ).

Ο AS ψάχνει στην βάση δεδομένων του για να ανακτήσει τα κλειδιά του χρήστη (user key) και του application server (server key). Παράγει με τυχαίο τρόπο το session key και ελέγχει τα πεδία με τις επιλογές του client όσον αναφορά το ticket. Σε απάντηση, ο AS επιστρέφει το session key, την διάρκεια ζωής του ticket και του session key, τον τυχαίο αριθμό από την αίτηση και το όνομα του application server, όλα αυτά κρυπτογραφημένα με το μυστικό κλειδί – κωδικό του χρήστη (user key). Μαζί αποστέλλει και το ticket που περιέχει τις ίδιες πληροφορίες που αναφέρθηκαν πριν, κρυπτογραφημένες με το server key. Το ticket θα προωθηθεί από τον client στον server σαν μέρος της αίτησης εξυπηρέτησης. Το ticket έχει ρυθμιστεί σύμφωνα με τις επιλογές του client.

Όταν ο client παραλάβει την authentication response, κατ' αρχή ελέγχει κατά πόσο ο τυχαίος αριθμός που είχε συμπεριλάβει στην αίτηση ταιριάζει με αυτόν που περιέχεται στο παραληφθέν μήνυμα. Γι' αυτό το σκοπό χρησιμοποιεί το κλειδί του χρήστη (user key) για να ανακτήσει το session key και το ticket. Αφού επιβεβαιώσει ότι η απάντηση ανταποκρίνεται στην αυθεντική αίτηση, αποκλείονται έτσι την πιθανότητα επίθεσης replay attack, συνεχίζει με την επεξεργασία του υπόλοιπου μηνύματος. Το γεγονός ότι τα περιεχόμενα της authentication response ήταν κρυπτογραφημένα με το κλειδί του χρήστη, αποδεικνύει ότι η απάντηση προέρχεται από τον αληθινό AS, ενώ το γεγονός ότι ο client μπορεί να αποκρυπτογραφήσει τα περιεχόμενα της απάντησης σημαίνει ότι αντιπροσωπεύει τον έγκυρο χρήστη.

Η ανταλλαγή μηνυμάτων αυτού του σταδίου χρησιμοποιείται από application servers του δικτύου για να πιστοποιήσουν την ταυτότητα του client και κατ' επέκταση την ταυτότητα του χρήστη, και αντιστρόφως. Ο client πρέπει πρώτα να έχει στην κατοχή του τα διαπιστευτήρια για την συγκεκριμένο application server.

Η παροχή μόνο του ticket στην αίτηση εξυπηρέτησης δεν αποτελεί ικανοποιητικό στοιχείο για την απόδειξη της ταυτότητας του client. Το ticket μπορεί να χρησιμοποιηθεί από εισβολέα που έχει καταγράψει την διακινούμενη πληροφορία. Η συνοδεία του ticket με επιπλέον πληροφορία (authenticator) που είναι δεμένη με την ταυτότητα του client, εξασφαλίζει ολοκληρωμένη επαλήθευση. Στο authenticator περιλαμβάνεται ένα checksum. Checksum είναι η hash ή digest value του μηνύματος κρυπτογραφημένη με το session key ή άλλο κλειδί.

Μία αίτηση εξυπηρέτησης αποτελείται από δύο μέρη: την απόδειξη – ticket και το πιστοποιητικό – authenticator. Το authenticator περιλαμβάνει την τρέχουσα ώρα, ένα checksum, ένα προαιρετικό κλειδί κρυπτογράφησης και στοιχεία της ταυτότητας του χρήστη όλα κρυπτογραφημένα με το session key. Το προαιρετικό κλειδί κρυπτογράφησης μπορεί να χρησιμοποιηθεί για κρυπτογράφηση των μελλοντικών μηνυμάτων μεταξύ application server και client.

Τα authenticators δεν μπορούν να ξανά χρησιμοποιηθούν και για κάθε αίτηση εξυπηρέτηση, ακόμα και αν είναι για τον ίδιο application server, ετοιμάζεται καινούργιο. Authenticators που επαναλαμβάνονται θα απορριφθούν από τον application server.

Η πιστοποίησης της ταυτότητας του client βασίζεται στο πεδίο της τρέχουσας ώρας, στο authenticator και στο ticket.

Όταν ο application server παραλάβει την application request, αποκρυπτογραφεί το ticket με το server key και παίρνει το session key που περιέχεται στο ticket. Με το session key αποκρυπτογραφεί το autheticator και ανακτά τις πληροφορίες για την ταυτότητα του χρήστη και την ώρα αποστολής της αίτησης. Έπειτα ελέγχει το checksum, παράγοντας το δικό του hash value και συγκρίνοντας το με αυτό που προκύπτει από την αποκρυπτογράφηση του checksum. Τέλος ελέγχει το πεδίο της ώρας συγκρίνοντας την τρέχουσα ώρα με την ώρα που περικλείεται στο authenticator. Εάν διαφέρουν περισσότερο από πέντε λεπτά, το μήνυμα απορρίπτεται και θεωρείται προϊόν επίθεσης επανάληψης (replay attack).

Προαιρετικά, εάν υποστηρίζεται αμοιβαία πιστοποίησης ταυτότητας, ο application server πιστοποιεί την ταυτότητα του στον client. Για να το επιτύχει αυτό, ετοιμάζει την application response, όπου τοποθετεί την ώρα αποστολής που περιεχόταν στην αίτηση και την κρυπτογραφεί με το session key. Ο client όταν θα παραλάβει την απάντηση, θα την αποκρυπτογραφήσει με το session key και θα επιβεβαιώσει ότι περιέχει την σωστή ώρα αποστολής της αιτήσεως. Η ενέργεια αυτή θα πιστοποιήσει στον client ότι επικοινώνησε με τον αυθεντικό server.

Είναι δυνατόν να προκύψει κάποιο λάθος κατά την επιβεβαίωση της ταυτότητας του client οπότε ο application server ανταποκρίνεται με μήνυμα λάθους που περιλαμβάνει τον είδος του λάθους.

Όπου:

c = ταυτότητα του client,

v = ταυτότητα του application server (αλλιώς και verifier),

n = τυχαίος αριθμός,

K_c,v = session key,

K_c = user key,

K_v = server key T_c,v = ticket,

ts = timestamp, ck = checksum, K_subsession = προαιρετικό κλειδί κρυπτογράφησης (sub-session key)

Η παραπάνω συναλλαγή μηνυμάτων παρουσιάζει το εξής πρόβλημα: χρησιμοποιείται κάθε φορά που ο χρήστης θέλει να επικοινωνήσει με κάποιον application server και πρέπει να εισάγει το κλειδί – κωδικό του κάθε φορά που θέλει να αποκρυπτογραφήσει τα διαπιστευτήρια που στέλνονται από τον AS. Μία προφανής λύση του προβλήματος είναι η αποθήκευση του κλειδιού στον client. Αλλά κάτι τέτοιο μπορεί να προσθέσει επιπλέον κινδύνους. Ο εισβολέας που αποκτήσει αντίγραφο του κλειδιού μπορεί να προσποιηθεί ότι είναι ο αυθεντικός χρήστης.

Η επίλυση του προβλήματος γίνεται με την εισαγωγή ενός νέου server, του Ticket Granting Server (TGS). Ο TGS και ο AS είναι ξεχωριστοί server, παρ' όλο που μπορούν να βρίσκονται στο ίδιο μηχάνημα. Ο συνδυασμός τους αποτελεί το Key Distribution Center (KDC). Ο ρόλος του TGS είναι ο εξής: πριν να επικοινωνήσει με κάποιον application server ο client ζητά από τον AS, όπως θα έκανε για οποιοδήποτε application server, για τα απαραίτητα διαπιστευτήρια, ώστε να επικοινωνήσει πρώτα με τον TGS. Το ticket που παίρνει λέγεται ticket-granting ticket (TGT). Μετά την παραλαβή του TGT, ζητά κανονικό ticket για τον application server όχι από τον AS, αλλά από τον TGS. Εξάλλου, η απάντηση του TGS δεν κρυπτογραφείται με το user key αλλά με το session key που περιεχόταν στο TGT. Μέσα στην απάντηση από τον TGS περιέχεται καινούργιο session key που θα χρησιμοποιηθεί για την κρυπτογράφηση της υπόλοιπης ανταλλαγής μηνυμάτων.

Το πλεονέκτημα αυτής της μεθόδου είναι ότι ενώ οι κωδικοί – κλειδιά των χρηστών δεν αλλάζουν για μεγάλες χρονικές περιόδους (συνήθως μήνες), ένα session key από το TGT είναι έγκυρο μόνο για λίγες ώρες (τυπικά 8 ώρες). Σαν συνέπεια, η αποθήκευση των TGT δεν δημιουργεί σημαντικό ρίσκο και ο χρήστης χρησιμοποιεί τον κωδικό του μόνο κατά την διάρκεια του login.

Αφού ο client αποκτήσει το νέο session key, η διαδικασία συνεχίζεται όπως πριν, με την αποστολή των διαπιστευτηρίων στον application server.

Η μορφή του μηνύματος για αίτηση TGT είναι σχεδόν παρόμοια με την μορφή της αίτησης σε έναν AS. Η κυριότερη διαφορά είναι ότι η κρυπτογράφηση της απάντησης του TGS γίνεται με το session key, ενώ της απάντησης του AS γίνεται με το user key.

Η αίτηση στον TGS αποτελείται από πληροφορίες που πιστοποιούν την ταυτότητα του client στον TGS, την ταυτότητα του application server, την ζητούμενη ώρα λήξης του ticket και το TGT κρυπτογραφημένο με το server key του TGS.

Η απάντηση περιέχει τα διαπιστευτήρια για τον application server, κρυπτογραφημένα με το session key που ανέκτησε ο TGS από το TGT. Περιέχεται το καινούργιο session key που θα χρησιμοποιηθεί για την επικοινωνία με τον application server.

Σε περίπτωση λάθους, ο TGS ανταποκρίνεται με μήνυμα λάθους που περιέχει τον κατάλληλο κώδικά λάθους.

T_c,tgs = ticket-granting ticket,

K_tgs = TGS server key,

K_c,tgs = session key,

Υπάρχουν δύο τρόποι για την προστασία των δεδομένων. Με την εφαρμογή κρυπτογράφησης προστατεύεται το απόρρητο της επικοινωνίας, ενώ με την εφαρμογή hash αλγόριθμων διαφυλάσσεται η ακεραιότητα της πληροφορίας. Ο πρώτος τρόπος προστασίας παράγει τα μηνύματα τύπου KRB_SAFE και ο δεύτερος τρόπος παράγει τα μηνύματα τύπου KRB_PRIV.

Όταν ο χρήστης επιθυμεί να μπορεί να ανιχνεύει τυχών τροποποιήσεις των μηνυμάτων που λαμβάνουν χρησιμοποιεί τα μηνύματα τύπου KRP_SAFE. Παράγεται το checksum των δεδομένων του χρήστη μαζί με πληροφορίες ελέγχου, με hash αλγόριθμο, μη αντιστρέψιμο. Το αποτέλεσμα του hash αλγόριθμου κρυπτογραφείται με το session key ή άλλο προσυμφωνημένο κλειδί. Οι πληροφορίες ελέγχου περιλαμβάνουν ένα timestamp και έναν ακέραιο αριθμό ακολουθίας, που χρησιμοποιούνται για προσδιορισμό του μηνύματος και καταπολέμηση του φαινομένου της επίθεσης επανάληψης (replay attack).

Η εφαρμογή που λαμβάνει τέτοιο μήνυμα πρώτα ελέγχει την ώρα στο πεδίο timestamp και τον ακέραιο αριθμό ακολουθίας. Αν ο έλεγχος έχει θετικό αποτέλεσμα, υπολογίζεται το checksum των δεδομένων και της πληροφορίας ελέγχου και συγκρίνεται με το παραληφθέν checksum. Σε περίπτωση που η σύγκριση δεν πετύχει, επιστρέφεται στην πηγή του μηνύματος, μήνυμα που προειδοποιεί για την τροποποίηση του μηνύματος.

Χρησιμοποιείται από χρήστες που θέλουν εξασφαλίσουν την ακεραιότητα των ανταλλασσωμένων δεδομένων. Η εφαρμογή του χρήστη συλλέγει τα δεδομένα μαζί με την πληροφορία ελέγχου και τα κρυπτογραφεί με το sub-session key ή με το session key. Η πληροφορία ελέγχου περιλαμβάνει ένα timestamp και έναν ακέραιο αριθμό ακολουθίας, που χρησιμοποιούνται για προσδιορισμό του μηνύματος και καταπολέμηση του φαινομένου της επίθεσης επανάληψης (replay attack).

Όταν μία εφαρμογή λαμβάνει ένα κρυπτογραφημένο μήνυμα πρώτα αποκρυπτογραφεί τα δεδομένα και μετά από επεξεργασίας του αποφαίνεται εάν είναι τροποποιημένα. Έπειτα ελέγχει την ώρα στο πεδίο timestamp και τον ακέραιο αριθμό ακολουθίας. Δεδομένου ότι και οι δύο έλεγχοι είναι επιτυχής, το μήνυμα θεωρείται ότι έχει μεταδοθεί με ασφάλεια.

Τα κρυπτογραφημένα περιεχόμενα παράγονται με την εφαρμογή του καθορισμένου αλγόριθμου στα δεδομένα και σε βοηθητικές πληροφορίες που σχετίζονται με το αλγόριθμο. Οι μηχανισμοί κρυπτογράφησης που χρησιμοποιεί ο Kerberos πρέπει να μπορούν να εγγυηθούν την ακεραιότητα των δεδομένων και συνίστανται μέτρα για την προστασία από επιθέσεις λεξικού (dictionary attacks). Γι' αυτό το σκοπό προστίθονται τα βοηθητικά πεδία και checksum αλγόριθμοι. Οι checksum αλγόριθμοι εφαρμόζονται στα περιεχόμενα προς κρυπτογράφηση και στις βοηθητικές πληροφορίες. Το αποτέλεσμα τους συνοδεύει τα πραγματικά δεδομένα και κρυπτογραφείται μαζί με αυτά.

1. DES in CBC mode σε συνδυασμό με τον CRC-32 checksum αλγόριθμο.
2. DES in CBC mode σε συνδυασμό με τον MD4 checksum αλγόριθμο.
3. DES in CBC mode σε συνδυασμό με τον MD5 checksum αλγόριθμο.

Οι μηχανισμοί παραγωγής checksum μπορούν να διακριθούν σε αυτούς που το αποτέλεσμα των hash αλγόριθμων δεν κρυπτογραφείται και σε αυτούς που χρησιμοποιούνται μαζί με αλγόριθμους κρυπτογράφησης για την παραγωγή κρυπτογραφημένων hash values. Συνιστάται το πρώτο είδος μηχανισμών να εφαρμόζεται μόνο σε περιπτώσεις που ακολουθεί κρυπτογράφηση. Το δεύτερο είδος θεωρείται πιο ασφαλές.

Το Kerberos υποστηρίζει τους εξής μηχανισμούς παραγωγής checksum:

1. MD4 checksum algorithm.
2. MD4 σε συνδυασμό με τον DES.
3. MD5 checksum algorithm.
4. MD5 σε συνδυασμό με τον DES.

Μέχρι τώρα θεωρήσαμε ότι το δίκτυο ήταν αρκετά μικρό ώστε ένα Key Distribution Center, αποτελούμενο από έναν Ticket Granting Server και έναν Authentication Server, να είναι αρκετό για να εξυπηρετήσει τις ανάγκες όλων των μηχανών – client. Όσο μεγαλώνει το δίκτυο όμως, ο αριθμός των αιτήσεων αυξάνεται και η εξυπηρέτηση γίνεται αργή. Είναι πολλές φορές, λοιπόν, προτιμότερο έως και απαραίτητο να διαχωρίζουμε το δίκτυο σε μικρότερα κομμάτια που καλούνται realms, που το καθένα έχει το δικό του TGS και AS. Συνήθως τα όρια των realms ταυτίζονται με τα όρια των εταιριών, αν και αυτό δεν υποχρεωτικό.

Η διαδικασία cross-realm authentication επιτρέπει σε ένα χρήστη να αποδείξει την ταυτότητα του σε έναν application server διαφορετικού realm. Για να επιτευχθεί αυτό ο client ζήτα ένα TGT για τον απομακρυσμένο application server από τον τοπικό AS. Μία τέτοια ενέργεια απαιτεί ο τοπικός AS και ο απομακρυσμένος AS στον οποίο είναι εγγεγραμμένος ο απομακρυσμένος application server να μοιράζονται ένα κλειδί γνωστό ως cross-realm key. Ο client χρησιμοποιεί το αποκτηθέν TGT για να κάνει αίτηση για ticket από τον απομακρυσμένο AS για τον application server του άλλου realm. Ο απομακρυσμένος AS ανιχνεύει ότι το TGT έχει εκδοθεί σε διαφορετικό realm, βρίσκει το cross-realm key που μοιράζεται με τον AS του άλλου realm, επαληθεύει την εγκυρότητα του TGT και τέλος εκδίδει ticket και session key για τον client. Μέσα στο ticket περιέχεται έκτος από το όνομα του client αλλά και το όνομα του απομακρυσμένου realm.

Στην 4^η έκδοση του Kerberos, ήταν απαραίτητο για έναν AS να μοιράζεται cross-realm κλειδιά με όλους του απομακρυσμένους AS, γεγονός που δυσχέραινε αφάνταστα την επικοινωνία. Αρκεί να πούμε ότι για πλήρη διασύνδεση απαιτούνταν ανταλλαγή n² κλειδιών όπου n ο αριθμός των realms.

Σε αντίθεση, η 5^η έκδοση του Kerberos υποστηρίζει την ιεραρχική διανομή των κλειδιών. Τα realms κατανέμονται ιεραρχικά και κάθε realm μοιράζεται κλειδιά με τα θυγατρικά του realms και με το γονικό του. Για παράδειγμα το realm ISI.EDU μοιράζεται κλειδί με το realm EDU, το οποίο με την σειρά του μοιράζεται κλειδιά με τα MIT.EDU, USC.EDU και WASHINGTON.EDU. Η πιστοποίηση της ταυτότητας ενός client στο realm ISI.EDU σε ένα application server στο realm MIT.EDU γίνεται με την απόκτηση ενός TGT από τον AS στο ISI.EDU για το EDU, με χρήση αυτού του TGT για την απόκτηση νέου TGT από τον AS του EDU για τον AS του MIT.EDU και τέλος με αποστολή αίτησης στον AS του MIT.EDU ζητώντας ticket για επικοινωνία με τον application server.

Η λίστα όλων των realms τα οποία έχει διασχίσει αίτηση του client καταγράφονται στο τελικό ticket και ο authentication server του απομακρυσμένου realm πραγματοποιεί την τελική απόφαση για το κατά πόσο μπορεί να εμπιστευτεί το μονοπάτι που ακολουθήθηκε. Η επιλογή μικρότερων διαδρομών υποστηρίζεται από το μοντέλο, καθ' ότι μπορούν να βελτιώσουν την απόδοση της διαδικασίας.

1. Επιθέσεις του τύπου άρνησης εξυπηρέτησης (denial of service attack) δεν μπορούν να αντιμετωπιστούν με το Kerberos. Ένας εισβολέας μπορεί εκμεταλλευόμενος τις αδυναμίες του συστήματος να αποτρέψει έναν server από το να συμμετέχει στα κανονικά βήματα πιστοποίησης. Η ανίχνευση και η επιδιόρθωση τέτοιων καταστάσεων αφήνεται στα χέρια των διαχειριστών και των χρηστών.
2. Οι χρήστες πρέπει να κρατούν τους κωδικούς τους μυστικούς. Το Kerberos δεν είναι σε θέση να προστατέψει το δίκτυο από ασυνείδητους χρήστες που μοιράζουν τους κωδικούς τους ή που δεν είναι αρκετά προσεκτικοί για να τον κρατήσουν κρυφό.
3. Επιθέσεις που βασίζονται στην πρόβλεψη εύκολων κωδικών (password guessing attack) δεν αντιμετωπίζονται από τον Kerberos. Ένας εισβολέας με χρήση ενός λεξικού, μπορεί εύκολα να "σπάσει" μικρούς και εύκολους κωδικούς που αποτελούνται από λέξεις που μπορούν να βρεθούν σε λεξικό.
4. Κάθε μηχανή του δικτύου πρέπει να έχει ένα καλά ρυθμισμένο ρολόι. Μηχανές με ρυθμίσεις ώρας που διαφέρουν σημαντικά (πάνω από 5 λεπτά) μπορεί να δημιουργήσουν πρόβλημα στην πιστοποίηση των timestamps που εμπεριέχονται στα μηνύματα. Έτσι, ένας εισβολέας εκμεταλλευόμενος αυτή την αδυναμία μπορεί να πραγματοποιήσει επίθεση επανάληψης (replay attack). Ή ακόμα βρίσκοντας τον απαραίτητο χρόνο, να σπάσει αδύναμους κωδικούς χρηστών.

Kerberos page -- http://www.pdc.kth.se/kth-krb/

The Kerberos Network Authentication Service -- http://gost.isi.edu/info/kerberos/

Kerberos Mailing List -- http://www.mit.edu:8008/menelaus.mit.edu/kerberos/

Kerberos Reference Page -- http://www.contrib.andrew.cmu.edu/~shadow/kerberos.html

Βασικές Έννοιες