Kerberos

Kerberos basicsSearch on YouTubeBookmarkSaved

ThreatsSearch on YouTubeBookmarkSaved

Users wish to access services on servers across a network. Three threats exist:

Kerberos propertiesSearch on YouTubeBookmarkSaved

• Kerberos provides a centralized authentication server. It authenticates users to servers and servers to users.
• Kerberos relies on conventional (symmetric) encryption. It makes no use of public-key encryption.
• There are two versions: version 4 and version 5.
• Version 4 uses DES.

NotationSearch on YouTubeBookmarkSaved

The version 4 tables also use these keys. $K_C$ is the key derived from the password of the user. $K_{tgs}$ is the key shared by the AS and the TGS. $K_{c,tgs}$ and $K_{c,v}$ are session keys.

Kerberos version 4Search on YouTubeBookmarkSaved

Simple authentication dialogueSearch on YouTubeBookmarkSaved

The slides start with a simple dialogue:

$\text{(1)}\ C \rightarrow AS:\ ID_C \Vert P_C \Vert ID_V$

$\text{(2)}\ AS \rightarrow C:\ Ticket$

$\text{(3)}\ C \rightarrow V:\ ID_C \Vert Ticket$

$Ticket = E(K_V, [ID_C \Vert P_C \Vert ID_V])$

Only the AS and $V$ know $K_V$, so the client cannot change the ticket. This dialogue has two problems. The password goes over the network in clear in message 1. Also, the user must enter the password for each new service.

Ticket lifetime problemSearch on YouTubeBookmarkSaved

The real version 4 dialogue uses a ticket-granting ticket that the client reuses. The lifetime of this ticket causes a problem:

• If the lifetime is too short, the system repeatedly asks the user for the password.
• If the lifetime is too long, an opponent has a greater opportunity to replay the ticket.

The threat is that an opponent steals the ticket and uses it before it expires.

AS, tickets and TGSSearch on YouTubeBookmarkSaved

Version 4 uses DES to provide the authentication service.

Authentication server (AS):

• The AS knows the passwords of all users and stores them in a centralized database.
• The AS shares a unique secret key with each server.

Ticket:

• The AS creates a ticket after it accepts the user as authentic.
• The ticket contains the ID of the user, the network address of the user and the ID of the server.
• The ticket is encrypted with the secret key shared by the AS and the server.

Ticket-granting server (TGS):

• The TGS issues tickets to users who have been authenticated to the AS.
• For each new service, the client applies to the TGS and uses its ticket for authentication.
• The TGS then grants a ticket for that service.
• The client saves each service-granting ticket. It uses the ticket each time the user requests that service.

Version 4 message exchangesSearch on YouTubeBookmarkSaved

Table 15.1 and Figure 15.2 show three exchanges with six messages.

(a) Authentication service exchange, to get a ticket-granting ticket:

$\text{(1)}\ C \rightarrow AS:\ ID_C \Vert ID_{tgs} \Vert TS_1$

$\text{(2)}\ AS \rightarrow C:\ E(K_C, [K_{c,tgs} \Vert ID_{tgs} \Vert TS_2 \Vert Lifetime_2 \Vert Ticket_{tgs}])$

$Ticket_{tgs} = E(K_{tgs}, [K_{c,tgs} \Vert ID_C \Vert AD_C \Vert ID_{tgs} \Vert TS_2 \Vert Lifetime_2])$

The AS encrypts message 2 with $K_C$, the key derived from the password. Only a user who knows the password can decrypt it. The password itself does not go over the network.

(b) Ticket-granting service exchange, to get a service-granting ticket:

$\text{(3)}\ C \rightarrow TGS:\ ID_V \Vert Ticket_{tgs} \Vert Authenticator_C$

$\text{(4)}\ TGS \rightarrow C:\ E(K_{c,tgs}, [K_{c,v} \Vert ID_V \Vert TS_4 \Vert Ticket_V])$

$Ticket_V = E(K_V, [K_{c,v} \Vert ID_C \Vert AD_C \Vert ID_V \Vert TS_4 \Vert Lifetime_4])$

$Authenticator_C = E(K_{c,tgs}, [ID_C \Vert AD_C \Vert TS_3])$

The TGS decrypts the ticket and gets $K_{c,tgs}$. Then it decrypts the authenticator. $ID_C$ and $AD_C$ must match in the ticket and the authenticator, and $TS_3$ must be recent.

(c) Client/server authentication exchange, to get the service:

$\text{(5)}\ C \rightarrow V:\ Ticket_V \Vert Authenticator_C$

$\text{(6)}\ V \rightarrow C:\ E(K_{c,v}, [TS_5 + 1]) \quad \text{(for mutual authentication)}$

$Authenticator_C = E(K_{c,v}, [ID_C \Vert AD_C \Vert TS_5])$

In message 6, $V$ returns $TS_5 + 1$ under $K_{c,v}$. Only a server that can decrypt the ticket knows $K_{c,v}$. Thus the client knows the server is genuine.

Overview of KerberosSearch on YouTubeBookmarkSaved

The overview figure gives the same exchanges in six steps:

1. The user logs on to the workstation and requests service on the host.
2. The AS verifies the access right of the user in the database. It creates a ticket-granting ticket and a session key. It encrypts the results with a key derived from the password of the user.
3. The workstation prompts the user for the password and uses it to decrypt the incoming message. Then it sends the ticket and an authenticator to the TGS. The authenticator contains the name of the user, the network address and the time.
4. The TGS decrypts the ticket and the authenticator, verifies the request, then creates a ticket for the requested server.
5. The workstation sends the ticket and the authenticator to the server.
6. The server verifies that the ticket and the authenticator match, then grants access to the service. If mutual authentication is necessary, the server returns an authenticator.

Kerberos realmsSearch on YouTubeBookmarkSaved

Full-service environmentSearch on YouTubeBookmarkSaved

A full-service Kerberos environment has a Kerberos server, a number of clients and a number of application servers. It requires that:

• The Kerberos server has the user ID and hashed password of all participating users in its database. All users are registered with the Kerberos server.
• The Kerberos server shares a secret key with each server. All servers are registered with the Kerberos server.
• The Kerberos server in each interoperating realm shares a secret key with the server in the other realm. The two Kerberos servers are registered with each other.

Kerberos realmSearch on YouTubeBookmarkSaved

A Kerberos realm is a set of managed nodes that share the same Kerberos database.

• The database is on the Kerberos master computer system. Keep this system in a physically secure room.
• A read-only copy of the database can also be on other Kerberos computer systems.
• All changes to the database must be made on the master computer system.
• To change or access the database, you must have the Kerberos master password.

Request in another realmSearch on YouTubeBookmarkSaved

A client in realm A gets a service from a server in realm B in seven steps:

1. The client requests a ticket for the local TGS from the AS in realm A.
2. The AS sends a ticket for the local TGS.
3. The client requests a ticket for the remote TGS from the local TGS.
4. The local TGS sends a ticket for the remote TGS.
5. The client requests a ticket for the remote server from the TGS in realm B.
6. The remote TGS sends a ticket for the remote server.
7. The client requests the remote service from the server in realm B.

The remote TGS accepts the ticket from step 4 because the two Kerberos servers share a secret key.

Kerberos version 5Search on YouTubeBookmarkSaved

Differences from version 4Search on YouTubeBookmarkSaved

The slides list five areas where version 5 changes version 4:

Version 5 message exchangesSearch on YouTubeBookmarkSaved

Table 15.3 shows the version 5 exchanges.

(a) Authentication service exchange:

$\text{(1)}\ C \rightarrow AS:\ Options \Vert ID_C \Vert Realm_C \Vert ID_{tgs} \Vert Times \Vert Nonce_1$

$\text{(2)}\ AS \rightarrow C:\ Realm_C \Vert ID_C \Vert Ticket_{tgs} \Vert E(K_C, [K_{c,tgs} \Vert Times \Vert Nonce_1 \Vert Realm_{tgs} \Vert ID_{tgs}])$

$Ticket_{tgs} = E(K_{tgs}, [Flags \Vert K_{c,tgs} \Vert Realm_C \Vert ID_C \Vert AD_C \Vert Times])$

(b) Ticket-granting service exchange:

$\text{(3)}\ C \rightarrow TGS:\ Options \Vert ID_V \Vert Times \Vert Nonce_2 \Vert Ticket_{tgs} \Vert Authenticator_C$

$\text{(4)}\ TGS \rightarrow C:\ Realm_C \Vert ID_C \Vert Ticket_V \Vert E(K_{c,tgs}, [K_{c,v} \Vert Times \Vert Nonce_2 \Vert Realm_V \Vert ID_V])$

$Ticket_V = E(K_V, [Flags \Vert K_{c,v} \Vert Realm_C \Vert ID_C \Vert AD_C \Vert Times])$

$Authenticator_C = E(K_{c,tgs}, [ID_C \Vert Realm_C \Vert TS_1])$

(c) Client/server authentication exchange:

$\text{(5)}\ C \rightarrow V:\ Options \Vert Ticket_V \Vert Authenticator_C$

$\text{(6)}\ V \rightarrow C:\ E(K_{c,v}, [TS_2 \Vert Subkey \Vert Seq\#])$

$Authenticator_C = E(K_{c,v}, [ID_C \Vert Realm_C \Vert TS_2 \Vert Subkey \Vert Seq\#])$

Kerberos in practiceSearch on YouTubeBookmarkSaved

• At the time of the slides, there were two versions in use. Version 4 is restricted to a single realm. Version 5 allows inter-realm authentication and was in beta test.
• Kerberos version 5 is an Internet standard, specified in RFC 1510. Many utilities use it.
• To use Kerberos, you must have a KDC on your network. You must also have Kerberised applications on all participating systems.
• The major problem was US export restrictions. Kerberos could not be distributed outside the US directly in source format.
• Binary versions had to hide the entry points of the crypto routines and have no encryption. Otherwise, users had to reimplement the crypto libraries locally.

Quick self-testSearch on YouTubeBookmarkSaved

Give the three threats that Kerberos addresses.

A user pretends to be another user. A user alters the network address of a workstation. A user eavesdrops on exchanges and uses a replay attack.

Which type of encryption does Kerberos use?

Conventional (symmetric) encryption only. It makes no use of public-key encryption. Version 4 uses DES.

Write the simple authentication dialogue and give its problems.

(1) $C \to AS$: $ID_C \Vert P_C \Vert ID_V$. (2) $AS \to C$: $Ticket$. (3) $C \to V$: $ID_C \Vert Ticket$, with $Ticket = E(K_V, [ID_C \Vert P_C \Vert ID_V])$. The password goes in clear, and the user must enter the password for each new service.

Why is the lifetime of the ticket-granting ticket a problem?

If the lifetime is too short, the system repeatedly asks for the password. If it is too long, an opponent has more time to steal the ticket and replay it before it expires.

Write messages 1 to 6 of Kerberos version 4.

(1) $ID_C \Vert ID_{tgs} \Vert TS_1$. (2) $E(K_C, [K_{c,tgs} \Vert ID_{tgs} \Vert TS_2 \Vert Lifetime_2 \Vert Ticket_{tgs}])$. (3) $ID_V \Vert Ticket_{tgs} \Vert Authenticator_C$. (4) $E(K_{c,tgs}, [K_{c,v} \Vert ID_V \Vert TS_4 \Vert Ticket_V])$. (5) $Ticket_V \Vert Authenticator_C$. (6) $E(K_{c,v}, [TS_5 + 1])$.

Why does a stolen ticket not let an attacker get a service?

Each request also needs a new authenticator encrypted with the session key. The authenticator has a recent timestamp and must match $ID_C$ and $AD_C$ in the ticket. The attacker does not know the session key.

What is a Kerberos realm?

A set of managed nodes that share the same Kerberos database. The database is on a master system in a physically secure room. All changes are made on the master and need the Kerberos master password.

Give the seven steps of a request for service in another realm.

Request and get a ticket for the local TGS. Request and get a ticket for the remote TGS. Request and get a ticket for the remote server from the remote TGS. Request the remote service.

Give the five areas where version 5 differs from version 4.

Encryption system dependence, Internet protocol dependence, ticket lifetime, authentication forwarding and interrealm authentication.

What do you need to use Kerberos?

A KDC on your network, and Kerberised applications on all participating systems.