ITN 266 Steven Grimley

Homework 2: Authentication
1.
Kerberos is a secret-key network authentication protocol. Kerberos is
used to verify that the users are who they claim to be, and the network
services that they use are what services they claim to be. The Kerberos
protocol uses a cryptographic algorithm (such as DES, 3DES, or AES) for
encryption and authentication, and authenticates requests for network
resources. Kerberos uses the concept of a trusted third party relationship to
perform secure verification of users and services. It enables a client and a
server to be mutually authenticated before a connection is established. This
trusted third party is the Key Distribution Center (KDC). A KDC issues tickets
to users. The Kerberos server uses these tickets instead of user names and
passwords to authenticate users and network services. These tickets are
issues for a limited duration, usually a business day or some other assigned
time period.
When a client (or principal) wants to connect with an application server
(or verifier) using Kerberos, first the KDC shares a secret key with each of
them. The client could be a user, an application server, or any other network
entity that needs authenticating. The passwords or secret keys for each
principal need to be added to the KDC in advance of any negotiation
attempt. The KDC keeps these keys encrypted in a local database, and uses
this key to prove the clients identity and establish an encrypted session
between this client and the KDC. Now the KDC will issue a ticket (TGT) that
can be used to verify the clients identity to the application it is requesting to
use. This process shows that the KDC functions in two roles, as the
Authentication Service (AS) and the Ticket Granting Service (TGS). The
Authentication Service exchange is done only once between the client and
KDC. The KDC then supplies a Ticket Granting Ticket (TGT) the client will use
to obtain further tickets. If the client wishes to connect with several
application servers, it authenticates to the Key Distribution Center only once,
then uses the TGT it obtains to request more tickets for each application
through the TGS.
1

ITN 266 Steven Grimley

The Client Authentication Process
A client must first authenticate, using the KDC role as an
Authentication Service. The client requests a ticket from the KDC by giving
its name, an expiration time for the ticket to remain valid, the service
required (tgs), and other required information. If the client is found in the
KDCs database, the KDC will respond with reply with 2 items. The first is a
client ticket encrypted with the principals secret key, which contains a
session key, the expiration time, and its tgs service name. The second item
is the Ticket Granting Ticket (TGT), encrypted using the KDC secret key. The
client is unable to decrypt the TGT, and this is used to request tickets for
other services. If the client tries to modify this TGT, it will later be rejected
because the KDC will be unable to decrypt it. No password has been sent
over the network in clear text. The password is the session key exchanged
between the client and KDC, and is used locally by the KDC to encrypt the
ticket and locally by the principal to decrypt it. The client and the KDC now
share a session key that they will use to encrypt their communications. The
client can now prove its identity to the KDC by using this key, since it is the
only one who can decrypt the earlier ticket.

The Ticket Granting Service

Once the client has authenticated itself with the KDC, it can then
request to use particular services or applications. The client does not request
directly to the application server, but must again go through the KDC. The
client must first present several items to the KDC. These items include:
-

An authenticator that is encrypted with the session key and

contains a timestamp and a checksum. This is encrypted to prove
the clients identity (as it is the only one to know the session key),
the checksum is for proof the message isnt altered in transit, and
the timestamp is for proof the message is current. It is typical that
the KDC must respond to this message within 5 minutes, making

time synchronization across your network vital.

The TGT received during authentication with the KDC. This is used
to check the clients name, making sure the name matches with the
2

ITN 266 Steven Grimley

associated session key, in order to prevent impersonation. The KDC
-

also verifies the expiration time of the authentication.

The name of the application service the client wishes to connect

with.
An expiration time for the TGT.

After this information is presented, the KDC will respond to the client
with 2 tickets. The first will contain a new session key for the client and the
application server to use for verification and to encrypt their communications
with each other. This ticket is encrypted with the key shared between the
client and the KDC, and will contain the applications name and the expiration
time of this new ticket. The second ticket is the server ticket, and is
encrypted with the application servers secret key. It contains the new
session key shared with the client, the clients name, and the expiration
time. The client is responsible for forwarding this server ticket to the
application server. Since the server ticket is encrypted with the application
servers secret key, it can be used for verification purposes. It also verifies
the validity of the ticket by checking the expiration time enclosed in the
server ticket. They are now authenticated, there is mutual trust between the
client and the application server.
Once the client has established a connection with the application
server it was looking for, future communications are encrypted using the
shared session key received from Kerberos. This helps keep communications
between the application and client secure. The ticket granting process must
be followed for each application server the client wishes to connect with
using the TGT through the TGS.

Advantages of Kerberos
Kerberos offers many benefits to users. It allows a client and a server
to mutually authenticate before establishing a connection. Authentication is
critical to security. Many applications use a weak authentication mechanism,
like clear text passwords, and Kerberos provides an easy fix for this. It
manages secure authentication from a central location for many
applications. For each application that requires this service, Kerberos is a
3

ITN 266 Steven Grimley

reliable, simple and easy to manage solution. Kerberos also unloads
application servers from performing the time consuming task of
authentication and allows them to concentrate on their primary function.
Kerberos is an example of a single sign-on system and provides enterprises
with scalability and flexibility.
Kerberos provides cryptographic authentication through a combination
of secret key and strong data encryption. This ensures the integrity of
messages and data confidentiality. Symmetric key encryption allows for real
time authentication because it is fast because the same key is used to
encrypt and to decrypt the message.

Disadvantages of Kerberos
Kerberos is generally a very secure system, but like all protocols it has
some weaknesses. Any weaknesses with Kerberos are based on concepts
within the protocol and not the fundamental cryptography. The Kerberos
system is vulnerable to brute-force attacks. An attacker can just repeatedly
guess an accounts password until they are successful. If a user has a weak
password, it could be easily discovered. Another potential weakness of
Kerberos lies with the keys. Keys must be stored securely for the user and
server. If an attacker gains access to the keys, the entire network could be
compromised.
When implementing Kerberos, time synchronization is very important.
Tickets have time availability periods, and if the times are more than 5
minutes apart, authentication will not occur.
Perhaps the biggest disadvantage of a Kerberos system is that the KDC
provides a single point of failure on your network. If the KDC goes down, any
users would no longer be able to authenticate to any system on the network.
Loss of the KDC can have a critical impact to the network. A plan to work

ITN 266 Steven Grimley

around this should include multiple KDC systems that share information so
that end user access and productivity is never diminished.

2.
It seems like the trade-off of this type of approach would be with security.
This kind of ticket management sounds risky to me. Allowing a ticket that is
older than the specified time to be presented to the TGS could allow for an
attacker to hijack old tickets and present them to the TGS in hopes of gaining
access to your network applications. If the attacker were successful just
once, he could gain access to valuable information, and in some
circumstances could even be able to gain further access to your network
outside the original application. I would feel more comfortable using common
Kerberos ticket granting techniques, as they have been proven to be a
secure and efficient way to manage authentication.