-

SEMINAR REPORT
ON
KERBEROS
Submitted for partial fulfillment of award of the degree of
Bachelor of Technology
In
Electronics & Communication Engineering
Submitted By
ASHISH VERMA
(1319231020)
Under the Guidance of
(Mr. ARVIND KUMAR SINGH)
(Astt. Professor)

Deptt. of Electronics & Communication Engineering

G. L. BAJAJ INSTITUTE OF TECHNOLOGY AND MANAGEMENT
Plot no. 2, Knowledge Park III, Gr. Noida
Session: 2015-16

Deptt. of Electronics & Communication Engineering

G. L. BAJAJ INSTITUTE OF TECHNOLOGY AND MANAGEMENT
[Approved by AICTE, Govt. of India & Affiliated to Dr. A.K.T.U (formally U.P.T.U),
Lucknow]

CERTIFICATE

Certified that ASHISH VERMA have carried out the TECHNICAL

SEMINAR work presented in this report entitled KERBEROS for the
award of Bachelor of Technology in Electronics & Communication
Engineering

during

the

academic

session

2015-16

from

Dr.

A.K.T.U(formally U.P.T.U), Lucknow. The seminar work and studies

carried out by Student himself and the contents of the report do not form the
basis for the award of any other degree to the candidate or to anybody else.

(Mr. Arvind Kr. Singh)

(Mr. Mohan Singh)

(seminar guide)
(Astt. Professor)
Deptt. of ECE

(Seminar Coordinator)
(Astt. Professor)
Deptt. of ECE

H. O. D., Deptt. of ECE

Date:

ACKNOWLEDGEMENT
I would like to thank respected Mr. Mohan Singh Sir and Mr. Arvind Kr. Singh for
giving me such a wonderful opportunity to expand my knowledge for my own branch
and giving me guidelines to present a seminar report. It helped me a lot to realize of
what we study for.
Secondly, I would like to thank my parents who patiently helped me as I went through
my work and helped to modify and eliminate some of the irrelevant or un-necessary
stuffs.
Thirdly, I would like to thank my friends who helped me to make my work more
organized and well-stacked till the end.
Next, I would thank Microsoft for developing such a wonderful tool like MS Word. It
helped my work a lot to remain error-free.
Last but clearly not the least, I would thank The Almighty for giving me strength to
complete my report on time.

Ashish Verma
(1319231020)
3rd year, ECE Deptt.

TABLE OF CONTENT
Serial No.

Title

Page No.

LIST OF FIGURES
ABSTRACT
1.1INTRODUCTION TO KERBEROS
2.1 TERMINOLOGY AND CONVENTIONS
3.1 THE KERBEROS MODEL
4.1 THE INITIAL TICKET EXCHANGE
5.1 LIMITATIONS OF VERSION 4
5.1.1 ENVIRONMENTAL SHORTCOMINGS
6.1 TICKETS
6.2 PRE-AUTHENTICATION DATA
6.3 SUBSESSION KEY NEGOTIATION
6.4 SEQUENCE NUMBERS
6.4.1 PUBLIC-KEY CRYPTOSYSTEMS
6.4.2 SMARTCARDS
7.1 BENEFITS OF USING KERBEROS
7.2 MOTIVATION
8.1 DESIGN REQUIREMENTS OF KERBEROS
9.1 WHAT DOES KERBEROS DO?
9.2 ASSUMPTIONS KERBEROS MAKES
9.3 THE HIGH LEVEL DETAILS
9.4 SERVICE AUTHENTICATION
9.5 THE TICKET GRANTING SERVER
9.6 KERBEROS-VERSION 5 AUTHENTICATION DIALOGUE
10.1 KERBEROS LIMITATIONS
11.1 KERBEROS APPLICATIONS
11.1.1 CISCO IMPLEMENTATION OF KERBEROS CLIENT SUPPORT
11.1.2 KERBEROS COMPONENT IN WINDOWS 2000
REFERENCES

vii

LIST OF FIGURES
FIGURE NO.

TITLE

PAGE NO.

Figure 1. Getting and using an initial ticket....................1

Figure 2. Getting a service ticket..........5
Figure 3. Working of client server model.....6

ABSTRACT
Authentication is the process of proving ones identity to someone else. As
humans, we authenticate each other in many ways: We recognize each
others faces when we meet, we recognize each others voices on the
telephone.
An authentication protocol would run before the two communicating parties
in the system run some other protocol. The authentication protocol first
establishes the identity of the parties to each others satisfaction; only after
authentication do the parties get down to the work at hand. It is a
fundamental building block for a secure networked environment.
Kerberos is an authentication service developed at MIT (Massachusetts
Institute of Technology).that uses symmetric key encryption techniques and
a key distribution Centre; it is an add-system that can be used with existing
network.
Kerberos provides a means of verifying the identities of principals on an
open (unprotected) network. This is accomplished without relying on
authentication by the host operating system, without basing trust on host
address, without requiring physical security of all the hosts on the network,
and under the assumption that packets travelling along the network can be
read, modified, and inserted at will.
Kerberos performs authentication under these conditions as a trusted third
party authentication service by using conventional cryptography. It trusted in
the sense that each of its clients believes Kerbeross judgement as to the
identity of each of its other clients to be accurate.

The problem that Kerberos addresses is this: a distributed system in which

users at workstations wish to access services on servers distributed
throughout the network. We would like for servers to be able to restricted
access to authorized users and to be able to authenticate requests for service.
In this system the following three threats exist:
1. A user may gain access to a particular workstation and pretend to be
another user operating from that workstation.
2. A user may alter the network address of a workstation so that the requests
sent from the altered workstation appear to come from the impersonated
workstation.
3. A user may eavesdrop on exchanges and use a reply attack to gain
entrance to a server or to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to
services and data that he or she is not authorized to access. Kerberos
provides a centralized authentication server whose function is to authenticate
users to servers and servers to users.
Kerberos provides the following requirements:
1. Secure: a network eavesdropper should not be able to obtain the necessary
information to impersonate a user.
2. Reliable: Kerberos should be highly reliable and should employ a
distributed server architecture, with one system able to back up another.
3. Transparent: the user should not be aware that the authentication is taking
place, beyond the requirement to enter a password.
4. Scalable: the system should be capable of supporting large numbers of
clients and servers.

CHAPTER-1
KERBEROS
1.1 Introduction:
Kerberos gets its name from Greek mythology. Cerberus, also known as Kerberos, was a
three headed beast that guarded the Underworld and kept the living from entering the
world of the dead. Kerberos protocol design began in the late 1980s at the Massachusetts
Institute of Technology (MIT), as part of project Athena. It is a secure authentication
mechanism designed for distributed severs, which assumes the network is unsafe. It
enables a client and a server to mutually authenticate before establishing a connection.
The first public release was Kerberos version 4, which leads to the actual version (v5) in
1993 after a wide public review. It followed the IETF standard process and its
specifications are defined in Internet RFC 1510. Originally designed for UNIX, it is now
available for all major operating systems, freely from MIT or also through commercial
versions.
The problem that the Kerberos addresses is this: Assume an open distributed environment
in which users at workstations wish to access services on servers distributed throughout
the network. We would like for servers to restrict access to authorized users and to be
able to authenticate requests for service. In this environment, a work station cannot be
trusted to identify its users correctly to network services. In particular, the following three
threats exist:

A user may gain access to a particular workstation and pretend to be another user
operating from that workstation.

A user may alter the network address of a workstation so that the requests sent
from the altered workstation appear to come from the impersonated workstation.

A user may eavesdrop on exchanges and use a reply attack to gain entrance to a
server or to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to services and
data that he or she is not authorized to access. Rather than building in elaborate
authentication protocols at each server, Kerberos provides a centralized authentication
server whose function is to authenticate users to servers and servers to users. Unlike
most other authentication schemes, Kerberos relies exclusively on symmetric encryption,
making no use of public -key encryption.
Two versions of Kerberos are in common use. Version 4 is still widely used. Version 5
corrects some of the security deficiencies of version 4 and has been issued as a proposed
Internet Standard (RFC 1510).

CHAPTER-2
2.1 Terminology and conventions
A principal is the basic entity that participates in authentication.

In

most

cases

principal represents a user or an instantiation of a network service on a particular host.

Each principal is uniquely named by its principal identifier.
Encryption is the process of transforming data into a form that cannot be understood
without applying a second transformation. Second transformation can only be applied by
someone in possession of the corresponding decryption key.
A secret-key cryptosystem such as that defined by the Data Encryption Standard (DES)
[FIPS46] uses a single key for both encryption and decryption. Such an encryption key is
called a secret key.
A public-key cryptosystem such as RSA [Riv78] uses different keys for encryption and
decryption. One of the keys in the pair can be publicly known while the other must be
kept private. These keys are referred to as public and private keys respectively.
Plaintext is a message in its unencrypted form, either before the encryption
transformation has been applied, or after the corresponding decryption transformation is
complete. Ciphertext is the encrypted form of a message, the output of the encryption
transformation.

CHAPTER-3
3.1 The Kerberos Model
Kerberos was developed to enable network applications to securely identify their peers.
To achieve this, the client (initiating party) conducts a three-party message exchange to

prove its identity to the server (the contacted party). The client proves its identity by
presenting to the server a ticket (shown in figures as Tc,s) which identifies a principal and
establishes a temporary encryption key that may be used to communicate with that
principal, and an authenticator (shown in figures as Ac,s) which proves that the client is in
possession of the temporary encryption key that was assigned to the principal identified
by the ticket. The authenticator prevents an intruder from replaying the same ticket to the
server in a future session.
Tickets are issued by a trusted third party Key Distribution Center (KDC). The KDC,
proposed by Needham and Schroeder, is trusted to hold in confidence secret keys known
by each client and server on the network (the secret keys are established out-of-band or
through an encrypted channel). The key shared with the KDC forms the basis upon which
a client or server believes the authenticity of the tickets it receives. A Kerberos ticket is
valid for a finite interval called its lifetime. When the interval ends, the ticket expires; any
later authentication exchanges require a new ticket from the KDC.
Each installation comprises an autonomously administered realm and establishes its own
KDC. Most currently-operating sites have chosen realm names that parallel their names
under the Internet domain name system Clients in separate realms can authenticate to
each other if the administrators of those realms have previously arranged a shared secret.

CHAPTER-4
4.1 The initial ticket exchange
Figure 1 shows the messages required for a client to prove its identity to a server. The
basic messages are the same for Versions 4 and 5 of Kerberos though the details of the
encoding differ. A typical application uses this exchange when it first establishes a
connection to a server. Subsequent connections to the same server require only the final

message in the exchange (client caching eliminates the need for the first two messages
until the ticket expires).
In the first message the client contacts the KDC, identifies itself, presents a nonce (a
timestamp or other non-repeating identifier for the request), and requests credentials for
use with a particular server.
Upon receipt of the message the KDC selects a random encryption key K c,s, called the
session key, and generates the requested ticket. The ticket identifies the client, specifies
the session key Kc,s, lists the start and expiration times, and is encrypted in the key K s
shared by the KDC and the server. Because the ticket is encrypted in a key known only
by the KDC and the server, nobody else can read it or change the identity of the client
specified within it. The KDC next assembles a response, the second message, which it
sends to the client. The response includes the session key, the nonce, and the ticket. The
session key and nonce are encrypted with the clients secret key K c (in Version 4 all fields
are encrypted in Kc).
For clarity, the figures show a simplified version of the messages. Other message
fields present in the actual messages are less relevant to the present discussion.

3
1. Client
2. KDC

KDC: c, s, n

Client: {Kc,s ,n}Kc ,{Tc,s}Ks

3. Client

Server: {Ac}Kc,s ,{Tc,s}Ks

Figure 1: Getting and using an Initial Ticket

Upon receiving the response the client decrypts it using its secret key (usually derived
from a password). After checking the nonce, the client caches the ticket and associated
session key for future use.

In the third message the client presents the ticket and a freshly-generated authenticator to
the server. The authenticator contains a timestamp and is encrypted in the session key
Kc,s. Upon receipt the server decrypts the ticket using the key it shares with the KDC (this
key is kept in secure storage on the servers host) and extracts the identity of the client
and the session key Kc,s. To verify the identity of the client, the sever decrypts the
authenticator (using the session key Kc,s from the ticket) and verifies that the timestamp is
current.
Successful verification of the authenticator proves that the client possesses the session
key Kc,s, which it only could have obtained if it were able to decrypt the response from
the KDC. Since the response from the KDC was encrypted in K c, the key of the user
named in the ticket, the server may reasonably be assured that identity of the client is in
fact the principal named in the ticket.
If the client requests mutual authentication from the server, the server responds with a
fresh message encrypted using the session key. This proves to the client that the server
possesses the session key, which it could only have obtained if it was able to decrypt the
ticket. Since the ticket is encrypted in a key known only by the KDC and the server, the
response proves the identity of the server.
For greater detail on the messages in Version 4 of Kerberos the reader is referred to
[Ste88] and [Mil87]. Details about Version 5 can be found in.

4.2 The additional ticket exchange

To reduce the risk of exposure of the clients secret key K c and to make the use of
Kerberos more transparent to the user, the exchange above is used primarily to obtain a
ticket for a special ticket-granting server (TGS). The client erases its copy of the clients
secret key once this ticket-granting ticket (TGT) has been obtained,
The TGS is logically distinct from the KDC which provides the initial ticket service, but
the TGS runs on the same host and has access to the same database of clients and keys
used by the KDC (see Figure 2). A client presents its TGT (along with other request data)
to the TGS as it would present it to any other server (in an application request); the TGS
verifies the ticket, authenticator, and accompanying request, and replies with a ticket for a
new server. The protected part of the reply is encrypted with the session key from the

TGT, so the client need not retain the original secret key K c to decrypt and use this reply.
The client then uses these new credentials as before to authenticate itself to the server,
and perhaps to verify the identity of the server.
Once the authentication is established, the client and server share a common session key
Kc,s, which has never been transmitted over the network without being encrypted. They
may use this key to protect subsequent messages from disclosure or modification.
Kerberos provides message formats which an application may generate as needed to
assure the integrity or both the integrity and privacy of a message.

Figure 2: Getting a service ticket

CHAPTER-5
5.1 Limitations of Version 4
Version 4 of Kerberos is in widespread use, but some sites require functionality that it
doesnt provide, while others have a computing environment or administrative procedures
that differ from that at MIT. As a result, work on Kerberos Version 5 commenced in 1989,
fueled by discussions with Version 4 users and administrators about their experiences
with the protocol and MITs implementation.

5.1.1 Environmental shortcomings

Kerberos Version 4 was targeted primarily for Project Athena, and as such in some areas
it makes assumptions and takes approaches that are not appropriate universally:
a. Encryption system dependence: The Version 4 protocol uses only the Data
Encryption Standard (DES) to encrypt messages. The export of DES from the USA

is restricted by the U.S. Government, making truly widespread use of Version 4

difficult.
b. Internet protocol dependence: Version 4 requires the use of Internet Protocol (IP)
addresses, which makes it unsuitable for some environments.
c. Message byte ordering: Version 4 uses a "receiver makes right" philosophy for
encoding multi-byte values in network messages, where the sending host encodes
the value in its own natural byte order and the receiver must convert this byte order
to its own native order. While this makes communication between two hosts with the
same byte order simple, it does not follow established conventions and will preclude
interoperability of a machine with an unusual byte order not understood by the
receiver.
d. Ticket lifetimes: The valid life of a ticket in Version 4 is encoded by a UNIX
timestamp issue date and an 8-bit lifetime quantity in units of five minutes, resulting
in a maximum lifetime of 2114 hours. Some environments require longer lifetimes
for proper operation (e.g. a long-running simulation which requires valid Kerberos
credentials during its entire execution).

CHAPTER-6
6.1 Tickets
Version 5 tickets contain several additional timestamps and a flags field. These changes
allow greater flexibility in the use of tickets than was available in Version 4.
Each ticket issued by the KDC using the initial ticket exchange is flagged as such. This
allows servers such as a password changing server to require that a client present a ticket
obtained by direct use of the clients secret key K c instead of one obtained using a TGT.
Such a requirement prevents an attacker from walking up to an unattended but logged in
workstation and changing another users password.
Tickets may be issued as renewable tickets with two expiration times, one for a time in
the near future, and one later. The ticket expires as usual at the earlier time, but if it is
presented to the KDC in a renewal request before this earlier expiration time, a
replacement ticket is returned which is valid for an additional period of time. The KDC

will not renew a ticket beyond the second expiration indicated in the ticket. This
mechanism has the advantage that although the credentials can be used for long periods
of time, the KDC may refuse to renew tickets which are reported as stolen and thereby
thwart their continued use.
A similar mechanism is available to assist authentication during batch processing. A ticket
issued as postdated and invalid will not be valid until its post-dated starting time passes
and it is replaced with a validated ticket. The client validates the ticket by presenting it to
the KDC as described above for renewable tickets.
Authentication forwarding can be implemented by contacting the KDC with the
additional ticket exchange and requesting a ticket valid for a different set of addresses
than the TGT used in the request. The KDC will not issue such tickets unless the
presented TGT has a flag set indicating that this is a permissible use of the ticket. When
the entity on the remote host is granted only limited rights to use the authentication, the
forwarded credentials are referred to as a proxy (after the proxy used in legal and
financial affairs). Proxies are handled similarly to forwarded tickets, except that new
proxy tickets will not be issued for a ticket granting service; they will only be issued for
application server tickets.
In certain situations, an application server (such as an X Window System server) will not
have reliable, protected access to an encryption key necessary for normal participation as
a server in the authentication exchanges. In such cases, if the server has access to a users
ticket-granting ticket and associated session key (which in the case of single-user
workstations may well be the case), it can send this ticket-granting ticket to the client,
who presents it and the users own ticket-granting ticket to the KDC. The KDC then
issues a ticket encrypted in the session key from the servers ticket-granting ticket; the
application server has the proper key to decrypt and process this ticket.
Kerberos is concerned primarily with authentication; it is not directly concerned with the
related security functions of authorization and accounting. To support the implementation
of these related functions by other services, Version 5 of Kerberos provides a mechanism
for the tamper-proof transmission of authorization and accounting information as part of
a ticket. This information takes the form of restrictions on the use of a ticket. The
encoding of each restriction is not a concern of the Kerberos protocol, but is instead

defined by the authorization or accounting mechanism in use. Restrictions are carried in

the authorization data field of the ticket.
When a ticket is requested, restrictions are sent to the KDC where they are inserted into
the ticket, encrypted, and thus protected from tampering. In the protocols most general
form, a client may request that the KDC include or add such data to a new ticket. The
KDC does not remove any authorization data from a ticket; the TGS always copies it
from the TGT into the new ticket, and then adds any requested additional authorization
data. Upon decryption of a ticket, the authorization data is available to the application
server. While Kerberos makes no interpretation of the data, the application server is
expected to use the authorization data to appropriately restrict the clients access to its
resources.
Among other uses, the authorization data field can be used in a proxy ticket to create a
capability. The client requesting the proxy from the KDC specifies any authorization
restrictions in the authorization data, then securely transmits the proxy and session key to
another party, which uses the ticket to obtain limited service from an application server.
The Open Software Foundations Distributed Computing Environment uses the
authorization data field for the generation of privilege attribute certificates (PACs).
Privilege information is maintained by a privilege server. When a PAC is requested by a
client the privilege server requests a Kerberos ticket identifying the privilege server itself,
but restricting the groups to which the client belongs and specifying a DCE specific user
ID. The ticket is then returned to the client which uses it to assert its DCE user ID and
prove membership in the listed groups. In essence, the privilege server grants the client a
proxy authorizing the client to act as the privilege server to assert the listed DCE user ID
and membership in the listed groups. If the ticket did not include restrictions, it would
indicate that the client was the privilege server, allowing the client to assert any user ID
and membership in any group.

6.2 Pre-authentication data

In an effort to complicate the theft of passwords, the Kerberos Version 5 protocol
provides fields in the initial- and additional-ticket exchanges to support password
alternatives such as hand-held authenticators (devices which have internal circuitry used

to generate a continually changing password). In the initial ticket exchange, these fields
can be used to alter the key Kc in which the reply is encrypted. This makes a stolen
password useless since fresh information from a physical device is needed to decrypt a
response. The field can also be used to prove the clients identity to the KDC before any
ticket is issued. Doing this makes it a little more difficult for an attacker to obtain a
message that can be used to verify password guesses.
This pre-authentication data field is used by the client in the additional ticket exchange to
pass the ticket granting ticket to the KDC; since it is a variable-length array, other values
may be sent in the additional ticket exchange.

6.3 Subsession key negotiation

Tickets are cached by clients for later use. To avoid problems caused by the reuse of a
tickets session key across multiple connections, a server and client can cooperate to
choose a new subsession key which is used to protect a single connection. This
subsession key is discarded once the connection is closed.
Negotiation of subsession keys allows an application to protect the privacy of messages
broadcast to several recipients. The application can individually negotiate with each
recipient to use a common subsession key before beginning the broadcasts.

6.4 Sequence numbers

Kerberos provides two message formats for applications to protect their communications.
The KRB_SAFE message uses a cryptographic checksum to insure data integrity. The
KRB_PRIV message uses encryption to insure integrity and privacy. In Version 4 these
messages included as control information a timestamp and the senders network address.
With Version 5, an application may elect to use a timestamp (as before) or a sequence
number. If the timestamp is used, the receiver must record the known timestamps to avoid
replay attacks; if a sequence number is used the receiver must verify that the messages
arrive in the proper order without gaps.

6.4.1 Public-key cryptosystems:

The encryption specifications in Kerberos Version 5 are designed primarily for

secret-key cryptosystems, but we are considering support for public-key
cryptosystems. One advantage of such support will be the ability to interoperate with
the evolving certificate infrastructure for Privacy Enhanced Mail. There is also work
proceeding on the development of a hybrid Internet Authentication System (IAS)
that will provide interoperability between Kerberos and public key based systems
such as Digital Equipment Corporations DASS.

6.4.2 Smartcards: Several companies manufacture hand-held devices which can be

used to augment normal password security methods, and there is strong interest
within the industry to integrate one or more of these systems with Kerberos. Work is
underway to use the pre-authentication data field to pass the additional information
needed to use such devices.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

CHAPTER-7
7.1 Benefits of using Kerberos
Nothing is easier today than to catch credentials over a network. If we try to run a sniffer
in our environment we will see that we certainly get a login/password combination
within a few minutes. This could lead to an unauthorized use of our network services and
would certainly compromise all data present in our environment; even protected
confidential data, as most users are using only one password for every application.
Authentication is critical to security. Too many applications use a weak authentication
mechanism, like clear text passwords or, even worse, rely on the honesty of client
applications, known as authentication by assertion. However, it is not the primary role of
an application to manage security. Consider a mail server: its role is to deliver email
messages over the network to the appropriate recipients, but not to verify the users
identity! This is where Kerberos comes in. It has the advantage to manage secure
authentication from a central location, and for many applications. For each application

that requires this service, it is a reliable, simple and easy to manage solution to use
Kerberos. Furthermore, it unloads application servers from this time consuming
authentication task and allows concentrating on their primary function.

7.2 Motivation
If a set of users is provided with dedicated personal computers that have no network
connections, then a users resources and files can be protected by physically securing
each personal computer. When these users are served by a central time sharing system,
the time sharing operation must provide the security. The operating system can enforce
access control policies based on user identity and use the logon procedure to identify
users.
Today, neither of these scenarios is typical. More common is a distributed architecture
consisting of dedicated user work stations (clients) and distributed or centralized servers.
In this environment, three approaches of security can be envisioned:

1. Rely on each individual client workstations to assure the identity of its user or
users and rely on each server to enforce a security policy based on user
identification (ID).
2.

Requires that client systems authenticate themselves to servers, but trust the
client system concerning the identity of the user.

3. Requires the user to prove identity fro each service invoked. Also requires that
severs prove their identity to clients.
In a small, closed environment, in which all systems are owned and operated by a single
organization, the first or perhaps the second strategy may suffice. But in a more open
environment, in which network connections to other machines are supported, the third
approach is needed to protect user information and resources housed by the server. The
third approach is supported b Kerberos. Kerberos assumes distributed client/server
architecture and employs one or more Kerberos servers to provide an authentication
service.

CHAPTER-8
8.1 Design requirements of kerberos
Secure: A network eavesdropper should not be able to obtain the necessary
information to impersonate a user. More generally, Kerberos should be strong
enough that a potential opponent does not find it to be the weak link.

Reliable: For all the services that rely on Kerberos for access control, lack of
availability of the Kerberos service means lack of availability of the supported
services.

Hence, Kerberos should be highly reliable and should employ

distributed server architecture, with one system able to back up another.

Transparent: Ideally, the user should not be aware that authentication is taking
place, beyond the requirement to enter a password.

Scalable: The system should be capable of supporting large number of clients

and servers. This suggests a modular, distributed architecture.
To support these requirements, the overall scheme of Kerberos is that of a trusted
third-party authentication service that uses a protocol based on that proposed by
Needham and Schroeder. It is trusted in the sense that clients and servers trust Kerberos

to mediate their mutual authentication. Assuming the Kerberos protocol is well designed,
then the authentication service is secure if the Kerberos server itself is secure.

CHAPTER-9
9.1 What does Kerberos do?
How does Kerberos allow you to authenticate yourself? Let us try and co-relate this to
how does one authenticate himself in real life? Typically, you show your driver's license-or ID card, if you're not of driving age. What does this show? It shows that there is an
agency (the one that issued the license or card) that has linked a given identity to a
physical likeness. This physical likeness usually consists of a photo and some physical
stats, and is considered to be uncopiable.
The identity consists of a name and an address, and some other information, such as a
birth date. In addition, there may be some restrictions on what the named person can do;
for instance, he or she may be required to wear corrective lenses while driving. (In many
cases, this restriction is implicit: one can't drink until the age of 21, based on the birth
date on the card.) Finally, the identification has a limited lifetime, represented by the
expiration date on the card.

Note that this demonstration of identity is contingent on a number of things. First of all,
the card must not be tampered with (such as changing the birth date, or the name, or the
photo). Secondly, the person performing the authentication must accept the agency that
issued the card. (Many supermarkets won't accept out-of-state or even out-of-town ID's
when verifying checks.) There are some other concerns, such as that the person being
authenticated really hasn't changed in appearance or name, or that the card is stolen, and
so forth.
Kerberos works in basically the same way. It's typically used when a user on a network is
attempting to make use of a network service, and the service wants assurance that the
user is who he says he is. To that end, the user presents a ticket that is issued by the
Kerberos authentication server (AS), much as a driver's license is issued by the RTO.
The service then examines the ticket to verify the identity of the user. If all checks out,
then the user is accepted.
Therefore, this ticket must contain information linking it in a fool proof manner to the
user. Since the user and the service don't meet face to face, a photo is of no use.
Therefore, the ticket must demonstrate that the bearer knows something only its intended
user would know, such as a password. Furthermore, there must be safeguards against an
attacker stealing the ticket, and using it later.

9.2 Assumptions Kerberos Makes

Kerberos does make some assumptions about the environment it lives in. It assumes that
users won't make poor choices for passwords. If a user selects a password like
``password'' or ``nothing,'' then an attacker who intercepts a few encrypted messages will
be able to mount a dictionary attack, in which he tries password after password to see if it
decrypts messages correctly. Success means that the user's password has been guessed
and that the attacker can now impersonate the user to any verifier.
Similarly, Kerberos assumes that the workstations or machines are more or less secure,
that only the network connections are vulnerable to compromise. In other words,

Kerberos assumes that there is no way for an attacker to position himself between the
user and the client in order to obtain the password in that manner.

9.3 The (High Level) Details

Lets take a look at how Kerberos goes about things. Both the user and the service are
required to have keys registered with the Authentication Server. The user's key is derived
from a password that he chooses; the service key is a randomly selected key (since no
person is available to type in a password).
Let us imagine that messages are written on paper (instead of being electronic), and are
``encrypted'' by being locked in a strongbox by means of a key. In this ``box world,''
principals are initialized by making a physical key and registering a copy of the key with
the AS.

1. First the user sends a message to the AS: ``I, Samit Mehra User, would like to talk
to Yahoo Server.''

2. When the AS receives this message, it makes up two copies of a brand new key.
This is called the session key. It will be used in the direct exchange between user
and service.

3. It puts one of the session keys in Box 1, along with a piece of paper with the name
``Yahoo Server'' written on it. It locks this box with the user's key.
Why is this piece of paper here? Let us recall that this box is really just an
encrypted message, and that the session key is really just a sequence of random
bytes. If Box 1 only contained the session key, then the user wouldn't be able to
tell whether the response came back from the AS, or whether the decryption was
successful. By putting in ``Yahoo Server,'' the user (or more precisely, the user's
program) will be able to verify both that the box comes from the AS, and that the
decryption was successful.

4. It puts the other session key in a Box 2, along with a piece of paper with the name
``Samit Mehra User'' written on it. It locks this box with the service's key.

5. It returns both boxes to the user.

6. The user unlocks Box 1 with his key, extracting the session key and the paper
with ``Yahoo Server'' written on it.

7. The user can't open Box 2 (since it's locked with the service's key). Instead, he
puts a piece of paper with the current time written on it in Box 3, and locks it with
the session key. He then hands both boxes to the service.

8. The service opens the Box 2 with its own key, extracting the session key and the
paper with ``Samit Mehra User'' written on it. It then opens Box 3 with the session
key to extract the piece of paper with the current time on it. These items
demonstrate the identity of the user.
The timestamp is put in Box 3 to prevent someone else from copying Box 2 and
using it to impersonate the user at a later time. Because clocks don't always work
in perfect synchrony, a small amount of leeway (about five minutes is typical) is
given between the timestamp and the current time. In addition, the service
maintains a list of recently sent authenticators, to make sure that they aren't resent
in quick order.
You may wonder how the service is able to open Box 2, if there isn't anyone
``back there'' to type in a password. Well, the service key isn't derived from a
password. Instead, it's randomly generated, then stored in a special file called a
service key file. This file is assumed to be secure, so that no one can copy the file
and impersonate the service to a legitimate user.
In Kerberos parlance, Box 2 is called the ticket, and Box 3 is called the authenticator.
The authenticator typically contains more information than what is listed here. Some of
this added information arises from the fact that this is an electronic message (for
example, there is a checksum). There may also be an encryption key in the authenticator
to provide for privacy in future communications between the user and the service.

9.4 Service Authentication

Sometimes, the user may want the service to be authenticated in return. To do so, the
service takes the timestamp from the authenticator (Box 3), places it in Box 4, along with
a piece of paper with ``Yahoo Server'' written on it, locks it with the session key, and
returns it to the user. (Clearly, it must include something with the timestamp; otherwise, it
could simply return Box 3!)

9.5 The Ticket Granting Server

There is a subtle problem with the above exchange. It is used every time a user wants to
contact a service. But notice that he then has to enter in a password (unlock Box 1 with
the key) each time. The obvious way around this is to cache the key derived from the
password. But caching the key is dangerous. With a copy of this key, an attacker could
impersonate the user at any time (until the password is next changed).
Kerberos resolves this problem by introducing a new agent, called the ticket granting
server (TGS). The TGS is logically distinct from the AS, although they may reside on
the same physical machine. (They are often referred to collectively as the KDC--the Key
Distribution Center. The function of the TGS is as follows. Before accessing any regular
service, the user requests a ticket to contact the TGS, just as if it were any other service.
This ticket is called the ticket granting ticket (TGT).

After receiving the TGT, any time that the user wishes to contact a service, he requests a
ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with
the user's secret key, but with the session key that the AS provided for use with the TGS.
Inside that reply is the new session key for use with the regular service. The rest of the
exchange now continues as described above.

It's sort of like when you visit some workplaces. You show your regular ID to get a guest
ID for the workplace. Now, when you want to enter various rooms in the workplace,
instead of showing your regular ID over and over again, which might make it vulnerable
to being dropped or stolen, you show your guest ID, which is only valid for a short time
anyway. If it were stolen, you could get it invalidated and be issued a new one quickly
and easily, something that you couldn't do with your regular ID.
The advantage this provides is that while passwords usually remain valid for months at a
time, the TGT is good only for a fairly short period, typically eight hours. Afterwards, the
TGT is not usable by anyone, including the user or any attacker. This TGT, as well as any
tickets that you obtain using it, are stored in the credentials cache. There are a number of
commands that you can use to manipulate your own credentials cache, which we'll get to
in a moment.

9.6 Kerberos - version 5 authentication dialogue

A full-service Kerberos environment, consisting of a Kerberos server, a number of clients
and a number of
application servers, requires that the Kerberos server must have the user ID (UID) and
hashed passwords of all participating users in its database.

All users are registered with the Kerberos server. Such an environment is referred as a
realm. Moreover, the Kerberos server must share a secret key with each server and every
server is registered with the Kerberos server.
A simple authentication procedure must involve three steps:
1. The client C requests the user password and then send a message to the AS of the
Kerberos system that includes the users ID, the servers ID and the users password.
2. The AS check its database to see if the user has supplied the proper password for this
user ID and whether this user is permitted access to the server V. If both tests are passed,
the AS accept the user as authentic and must now convince the server that this user is
authentic. Thus the AS creates and sends back to C a ticket that contains the users ID and
network address and the servers ID. Then it is encrypted with the secret key shared by
the AS and the server V.
3. C can now apply to V for the service. It sends a message to V containing Cs ID and
the ticket. V decrypts the ticket and verifies that the user ID in the ticket is the same of
the one which came with the ticket. If these two match, the server grants the requested
service to the client.
This scheme is correct, but this is not enough in a distributed environment: it has some
leaks related to security and requires that the user introduce the password every time he
needs to access to a service. Indeed, the client sends its password unencrypted to the AS;
an eavesdropper could capture the password and use any services accessible to the victim.
Moreover, it is better to minimize the number of times that the user has to enter a
password.
To solve these additional problems, we introduce a scheme for avoiding plaintext
passwords and a new server, known as the Ticket-Granting Server (TGS). The new
service issues tickets to users who have been authenticated to AS. Each time the user
require access to a new service, the client applies to the TGS using the ticket supplied by
the AS to authenticate itself. The TGS then grants a ticket to the particular service and the
client saves this ticket for future use.
1. The client request a ticket-granting ticket on behalf of the user by sending its users ID
to the AS, together with the TGS ID, indicating a request to use the TGS service.

2. The AS responds with a message, encrypted with a key derived from the users
password that contains the ticket for the TGS. The encrypted message also contains a
copy of the session key used by C and the TGS. In this way, only the users client can
read it. The same session key is included in the ticket, which can be read only by the
TGS. Now C and the TGS share a common key.
3. Armed with the ticket and the session key, C is ready to approach the TGS. C sends the
TGS a message that includes the ticket plus the ID of the requested service. In addition, C
transmits an authenticator, which includes the ID and address of Cs user and a
timestamp; it is encrypted with the session key known only by C and TGS. Unlike the
ticket, which is reusable, the authenticator is intended to use only once and has a very
shot lifetime.
The TGS can decrypt the ticket with the key that it shares with the AS. This ticket
indicates that the user C has been provided with the session key Kc. Thus the TGS
decrypt the authenticator with Kc gained from the ticket and check the name and the
address from the authenticator with that of the ticket and with the network address of the
incoming message. If all match, then the TGS is assured that the sender of the ticket is
indeed the tickets real owner.

Fig.3 working of client-server model

Finally, at the conclusion of this process, the client and the server share a secret key. This
key can be used to encrypt future messages between the two or to exchange a new session
key for that purpose.
The Kerberos system is also able to manage more complicated situations which involve
more than one realm. Usually, networks of clients and servers under different
administrative organizations constitute different realms.
Sometimes, user in one realm may need access to server in other realms and they need to
be authenticated before to use services provided by those servers. Kerberos has a
mechanism for supporting such inter-realm authentication.

The only requirement requested is that the Kerberos server in each interoperating realm
shares a secret key with the server in the second realm. The two Kerberos server are
registered with each other.
The communication mechanism between a client and a server in two different realms is
the following:
1. The client C in the realm needs a ticket in order to communicate with the server in
the realm. Thus, the users client follows the usual procedures to gain access to the
local TGS and then request a ticket-granting ticket for the remote TGS in realm .
2. The client can then apply to the remote TGS for a service-granting ticket valid for the
desired server in that different realm. Distributed Systems Fall 2002
4
3. The client can now use the ticket obtained from the remote TGS with the server V in
the other realm.

CHAPTER-10
10.1 Kerberos limitations
Since Kerberos has many strengths, it has a number of limitations and some weakness in
its protocol which have made Kerberos is not as extended as it should be.
One of the main problems of Kerberos (which is not relative to security of the protocol) is
that any application which wants to use the Kerberos protocol, have to be modified in the
code in order to establish a secure communication. This means high costs in terms of time
and money, and is not reliable for all applications nor enterprises.
The timestamps are used to establish secure communication. Therefore, servers have to
be synchronized within no more than a few minutes, and for instance, times servers are
required to synchronized often their clocks. But then, "if a host can be misled about the
correct time, a stale authenticator can be replayed without any trouble at all". A solution
to this problem could be performed by "adding challenge/response as alternative to timebased authentication".
Another problem relative to security relies on the high dependency on the Kerberos
server. If this server goes down, then the whole network goes down as well. This is
something very expensive and not desirable in a distributed system. In addition to this, all
security relies on the server, so if someone can access the Kerberos server, then all
network connection could be hacked.
There is another potential problem which is that someone could steal from the network
the message from the
AS to the client, this message, as we have seen above, is encrypted by the client key
which is derivated from the client password. Therefore, someone could try to guess this
key and then he would be able to identify himself as the original client. "Kerberos is not
effective against password guessing attacks; if a user chooses a poor password, then an
attacker guessing that password can impersonate the user". A solution proposed is the
using of "exponential key exchange to provide an additional layer of encryption [...] it
involves the two parties exchanging numbers that each can use to compute a secret key.
An outsider, not knowing how the numbers were calculated, cannot easily derive the
key".

Kerberos by itself cannot guarantee that the password will not travel along the net. It can
happen that "the user enters a password to a program that has already been modified by
an attacker (a Trojan horse), or if the path between the user and the initial authentication
program can be monitored, then an attacker may obtain sufficient information to
impersonate the user." Kerberos must be combined with other techniques to address these
limitations.
Kerberos is designed to authenticate clients which are users, but "Kerberos is not a hostto-host protocol". Even thougth, in last version 5, it has been extended to user-to-user
authentication.
These limitations have made Kerberos became a protocol not as extended nor used as it
should be. Most of the networks only need an encrypted communication protocol to
establish a minimum security, therefore sometimes Kerberos is replace by programs as
simple and transparent as SSH.

CHAPTER-11
11.1 Kerberos applications
11.1.1 Ciscos implementation of Kerberos client support
To implement a Kerberos security system with a Cisco router remote, users attempting
network services must pass through three layers of security before they can access
network services.
The first one is called Authentication to the Boundary Router and describes the
operations to follow in the authentication process. A remote user who successfully
initiates a PPP session to the corporate site is prompted by the router in order to register
himself with login and password. Although in this phase the user is inside the firewall, to
gain access to the network services, it still must authenticate to the Key Distribution
Centre (KDC). This because the TGT issued by the KDC is stored on the router and is
not useful for additional authentication unless the user physically logs on the router.
Therefore the next step is Obtaining a TGT from a KDC. At this point, the client launches
the KINIT program which is part of the software provided with Kerberos protocol.
KINIT finds the users identity and requests a TGT from the KDC. When the KINIT
program receives the encrypt TGT, it prompts the user for the password to decrypt the
ticket if it is successfully, the user has a TGT and can communicate securely with the
KDC.
The third and last layer describes how the client, with a TGT, authenticates to network
services within a given Kerberos realm. To make it possible the router must share a secret
key with the KDC. To do this, you must give the router a copy of the SRVTAB you
extracted on the KDC. This file contains the passwords or randomly generated keys for
the service principals you entered into the KDC database.
The most secure method to copy SVRTAB files to the hosts in your Kerberos realm is to
copy them manually in each host in turn. For the router, instead, you must transfer them
via the network using the TFTP. Finally the user is authenticate to the network service.
The entire process described above is repeated each time a user wants to access a network
service in the Kerberos realm.

11.1.2 Kerberos component in Windows 2000

Windows 2000 uses the domains Active Directory to implement in the KDC the action
of getting some information about users from the Global Catalogue.
The KDC is located on every domain controller, as is the Active Directory service. Both
services are started automatically by the Local Security Authority (LSA) of the domain
controller and they run in the process space of the LSA. Its supposed that neither service
can be stopped.
Windows 2000 ensures availability of these services by allowing each domain to have
several domain controllers, all peers. Any domain controller can accept authentication
requests and ticket-granting requests addressed to the domain's KDC.

References
[1] J. Kohl C. Neuman, RFC 1510, The Kerberos Network Authentication Service (V5),
September 1995
[2] William Stallings, Cryptography and Network security (Principle and Practice), Upper
Saddle River N.J., Prentice Hall 1999
[3] Steven M. Bellowin and Michael Merit from AT&T Bell Laboratories, Limitations of
the Kerberos Authentication System, Winter '91 USENIX Conference Proceedings,
USENIX Association, 1991
[4]

1992--2001

Cisco

Systems,

Inc.

All

rights

reserved

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt
2/scdkerb.htm, August 2001
[5] Mahmoud T. El-Hadidi, Nadia H. Hegazi, Heba K. Aslan, Performance Analysis of
the Kerberos Protocol in a Distributed Environment, 2nd IEEE Symposium on
Computers and Communication (ISCC 1997).
Distributed Systems Fall 2002