Kerberos

---

History

Developed at MIT in the 80's.
Released as open-source in 1989. Assumptions of Kerberos:

• Password guessing attacks are not solved by Kerberos, a weak password will allow an attacker to crack a key
• Kerberos assumes that network devices are secure and that no-one is allowed to perform a man-in-the-middle attack
• passwords must be secret
• DoS attacks of the flood type are not solved by Kerberos
• clocks of clients and servers must be in sync
• the Authentication Server MUST be secure
• device identifiers must not be recycled on a short term basis

Definitions in Kerberos Authentication

• Realm - Organizational Boundary. Each realm has an AS, TGS which together are called a KDC
• Key Distribution Center (KDC) - the AS and TGS
• Authentication Server (AS) - Registers valid users in the Realm and provides a TGT
• Ticket-Granting Server (TGS) - grants a ticket to a client with a TGT
• Ticket - The ticket proves a users identity to a service
• Ticket-granting Ticket (TGT) - Granted upon successful Authentication, it allows the authenticated user to request tickets for services in the Realm
• Authenticators - bits used for validation, only used once and expire after 5 minutes.
• Principal - Any entity that can be granted a ticket.

Authentication Process

1. Client A sends username in a request to authentication Server (AS) for 'credentials' to access a service on Server B, which is on another host (server). Other authenticating data (often in the form of a hand-entered key at the time of the installation of the Kerberized clients, installation. Additionally I believe that some systems use the hash of the users password.) is sent along with request.
2. The AS checks to see if the username is a valid username in the security database for the AS'es Realm.
3. If the username is valid, a random session key and a ticket consisting of the clients name, the name of the TGS, current time, ticket lifetime, clients IP address and a random session key encrypted with the users password hash is sent back to the client. (Note that the password itself has not been sent)
4. Once the response from the AS has been received by the client from the AS, the client uses it's password hash to decrypt the TGT that it got from the AS. then creates 2 session keys or tickets of which one is encrypted using the master key (that is the password and other hand-entered data key) from Client A and another ticket is encrypted with Server B's master key. Client A is sent BOTH keys.
5. Client A decrypts ticket A using Client A's master key, at which time Client A then knows that it has been authenticated. Client A then adds an authenticator (which contains a timestamp and username) to the ticket and uses the session key to encrypt Client A's session key. Client A then sends the 2 keys to the Server B, they are ClientA's session key which is the session key that was sent from the AS + the authenticator and ServerB's key.
6. ServerB then opens the ServerB's key which was generated from the AS with ServerB's master key and extracts the session key. Using the session key it opens the authenticator key (ClientA's key+authenticator), verifies the timestamp, username and checksum. At that point services become available to ClientA if ClientA is authorized.

| Kerberos at RSA Labs | RFC 1510 Kerberos | RFC 2712 Kerberos and TLS |    

---

| Top |