Kerberos

1/16

This material was developed with funding from the National Science Foundation under Grant # DUE 1601612

Next

Restart

Back

Kerberos Overview

ACME Corp Application Server

2/16

Authentication is the process used to determine whether a user is, in fact, who or what he or she claims to be. Let’s say Bob, a client, wants to access resources on an application server at ACME Corp. To do this, Bob will use his username and provide a password. Since the network is built on TCP/IP, an unsecure protocol suite, Bob does not necessarily trust the network he’s on and he does not know who might be able to listen in on his communication. This is where Kerberos comes in.

3/16

Kerberos is a network authentication protocol that uses strong encryption to provide authentication for client-server applications. The protocol’s name was derived from the Greek mythology character, Cerberus, the ferocious three-headed guard dog of Hades that prevents the dead from escaping.

The Kerberos Name

The Application Server, the Service

The three heads of the Kerberos protocol include the client, a service and the Key Distribution Center (KDC), a third-party that both the client and service trust. The KDC contains an Authentication Server (AS) and a Ticket Granting Server (TGS). The Kerberos protocol uses strong cryptography so that Bob, the client, can prove his identity to a server and the server proves its identity to Bob. Kerberos issues tickets as part of this process. 

Key Distribution Center (KDC)

4/16

APP1

AS

The “three heads” of Kerberos

TGS

Close 

Domain Controller a server that runs a version of the Windows Server operating system and has Active Directory installed

5/16

2/8

Secret keys

Kerberos Platforms

Active Directory a hierarchical structure that stores information about objects on the network to make it easier for administrators and users to find and use. 

In a Windows environment, Kerberos is part of its Active Directory. The KDC processes run on all Domain Controllers, and Kerberos uses the Active Directory database. The KDC stores the secret keys for user machines and services in its database. KDC’s and Kerberos clients can be run on many platforms such as Linux and Apple. The secret keys are symmetric—whatever a key encrypts is the same key used to decrypt. The application server that Bob is requesting access to never communicates directly with the KDC.

Hashing function used to generate a value from a string of text using a mathematical algorithm to protect the security of the text string. 

Keytab a file containing a collection of Principles (such as Service Principal Names or User Principal Names) and associated keys

G00dDog

Bob enters his password, and that password is sent through a hashing function resulting in a long-lived symmetric key (a password’s lifetime is typically 90 days). The application server has a symmetric key stored in a keytab file. The keytab file contains a randomly generated long-lived symmetric key. The ticket granting server also has a long-lived symmetric key. The authentication server maintains a copy of all the keys in KDC’s realm: the keys generated by Bob, the application server and TGS.

6/16

Password:

Login

#

Bob needs access to the application server. After entering his password that creates his key, Bob’s computer constructs a package that consists of his user ID, the service he is requesting, and his IP address, all in cleartext. To prove that he is Bob, a timestamp (ts) is generated and encrypted.  Drag and drop Bob’s key on the timestamp to encrypt it.

The entire package is sent over the unsecured network to the authentication server. When the AS receives the package, it sees someone claiming to be Bob. Use the proper key to decrypt the timestamp.

7/16

Drag and drop the appropriate key to decrypt the timestamp

Does Bob Exist?

Drag and drop Bob's key on the timestamp to encrypt it.

Drag and drop the appropriate AS key on the first package to encrypt it.

The authentication server creates two packages. The first package contains a random short-lived session key shown in red, a timestamp, the TGS name and an expiration. This package is going back to Bob. Drag and drop the proper AS key on the first package to encrypt it. The second package is the ticket granting ticket (TGT). The TGT consists of the red session key, Bob’s user ID, the TGS name, a timestamp, Bob’s IP address, and an expiration. Session keys and encryption both require an imposed lifetime. The more time available to a hacker to decipher encryption keys or ciphertext, the more likely the chance of success. Timestamps also mitigate the risk of a hacker capturing Kerberos traffic and replaying it back to the KDC later.

Generating the TGT

Session key a randomly generated key to ensure the security of a series of interactions between two communication endpoints (a user and computer) 

8/16

The authentication server uses the TGS’s black key to encrypt and protect the TGT. Both packages are sent to Bob. Bob receives the packages. Decrypt the first package using the appropriate key.

Drag and drop the appropriate key to decrypt the first package.

Yes

No

The TGS Session Key

Bob now has the red session key and the name of the ticket granting server.

Q: Can Bob decrypt the TGT?

Bob cannot decrypt the TGT since it was encrypted with the ticket granting server’s black key.

9/16

10/16

Requesting Access to a Service

Bob creates a new package with his user ID and a timestamp and encrypts this package with the red session key. Bob also creates a cleartext message stating that he needs access to the application server. All three packages go on to the ticket granting server (TGS). Bob keeps a copy of the red session key and the TGT.

I need access to APP1

Drag and drop the appropriate key to decrypt the packages at the TGS

11/16

Q: Which package gets decrypted first at the TGS?

Perform the next step by using the appropriate key to decrypt the packages at the TGS. Now that the ticket granting server also has a copy of the red session key, the TGS uses it to decrypt Bob’s message. The ticket granting server compares the two packages. If they match, it means that Bob sent the packages AND Bob properly checked out with the authentication server.

user package

TGT

Verify the Service Request

service request

The Service Session Key

The TGS will fulfill Bob’s request to access the application server, APP1. The TGS gets the application server’s gold key from the AS. The TGS then creates two packages. The first one, the Service Ticket, contains a second randomly generated session key (the green key), Bob’s ID, his IP address, the timestamp, and the expiration. The TGS uses APP1’s gold key to encrypt the package. The second package contains the green session key, the application server name, a timestamp and an expiration. Both packages are going back to Bob. Drag and drop the appropriate key from the TGS to encrypt the second package.

12/16

Drag and drop the appropriate key to encrypt the second package

service ticket

13/16

Use the appropriate key to decrypt the necessary package. After decrypting the package, Bob gets the green session key. Now Bob needs to prove to the application server that he is user BobV.

Q: What package should Bob decrypt first?

Package containing APP server name

Drag and drop the appropriate key to decrypt the necessary package

14/16

I am Bob

Bob creates a new package with his user ID and a timestamp. This package will be sent to APP1. Use the appropriate key to encrypt the new package. Both packages get sent to the application server. Bob maintains a copy of the Service Ticket and the session key just in case he needs to repeat the process in the near future.  At all stages, only the KDC can read the TGT and only the service, APP1, can read the Service Ticket.

Drag and drop the appropriate key to encrypt the new package

Drag and drop the appropriate keys in the proper sequence to decrypt the packages.

HINT

First decrypt the Service Ticket using the gold key. APP1 now has the green session key, so you can decrypt the second package proving that the user on the other end is BobV.

Drag and drop the appropriate key ito decrypt the package.

It is Bob

The application server now has both packages. Use the appropriate keys in the proper sequence to decrypt the packages.

15/16

16/16

Bob now knows that the application server, APP1, is on the other end. Since Bob cached the Service Ticket, he can use that to re-authenticate for any subsequent visits back to APP1 if he is within the expiration time period. Bob also cached the TGT which means that if he authenticates to another application server, he can present that TGT back to the ticket granting server. The process to issue a service ticket would be repeated in the background and Bob does not have to enter his password again if he is within the expiration period.

Drag and drop the appropriate key to decrypt the package.

To prove its identity to Bob, the application server creates a new package. Encrypt the new package with the appropriate key.

Proving the Identity of APP1

Drag and drop the appropriate key to encrypt the package.

Bob receives the package. Use the appropriate key when Bob receives it to decrypt.