KERBEROS

By
R.Venkatesh
AP/CSE
 Kerberos
Kerberos is an authentication service developed as part of
Project Athena at MIT.
The problem that 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 be able to restrict
access to authorized users and to be able to
authenticate requests for service.
In this environment, a workstation cannot be trusted
to identify its users correctly to network services.
Contd.,
In particular, 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 replay
attack to gain entrance to a server or to disrupt operations.
Contd.,
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.
Two versions of Kerberos are in common use.
Version 4 - implementations still exist.
Version 5 - corrects some of the security deficiencies of
version 4 and has been issued as a proposed Internet Standard.
Contd.,
Motivation
If a set of users is provided with dedicated personal
computers that have no network connections, then a user’s
resources and files can be protected by physically securing
each personal computer.
When these users instead are served by a centralized time-
sharing system, the time-sharing operating system must
provide the security.
The operating system can enforce access-control policies
based on user identity and use the logon procedure to
identify users.
Contd.,
More common is a distributed architecture consisting of
dedicated user workstations (clients) and distributed or
centralized servers.
In this environment, three approaches to security can be
envisioned.
1. Rely on each individual client workstation 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. Require that client systems authenticate themselves to servers,
but trust the client system concerning the identity of its user.
3. Require the user to prove his or her identity for each service
invoked. Also require that servers prove their identity to clients.
Contd.,
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 at the server.
Kerberos supports this third approach.
Kerberos assumes a distributed client/server architecture
and employs one or more Kerberos servers to provide an
authentication service.
Requirements
The first published report on Kerberos [STEI88] listed the following
requirements.
Secure: A network eavesdropper should not be able to obtain the
necessary information to impersonate a user.
Reliable: For all 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 a
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 numbers of
clients and servers.
Kerberos Version 4
Version 4 of Kerberos makes use of DES, in a rather
elaborate protocol, to provide the authentication service.
Viewing the protocol as a whole, it is difficult to see the
need for the many elements contained therein.
Therefore, we adopt a strategy used by Bill Bryant of
Project Athena and build up to the full protocol by looking
first at several hypothetical dialogues.
Each successive dialogue adds additional complexity to
counter security vulnerabilities revealed in the preceding
dialogue.
After examining the protocol, we look at some other
aspects of version 4.
A Simple Authentication Dialogue
In an unprotected network environment, any client can
apply to any server for service.
The obvious security risk is that of impersonation.
An opponent can pretend to be another client and obtain
unauthorized privileges on server machines.
To counter this threat, servers must be able to confirm the
identities of clients who request service.
Each server can be required to undertake this task for each
client/server interaction, but in an open environment, this
places a substantial burden on each server.
Contd.,
An alternative is to use an authentication server (AS) that
knows the passwords of all users and stores these in a
centralized database.
In addition, the AS shares a unique secret key with each
server.
These keys have been distributed physically or in some
other secure manner.
Consider the following hypothetical dialogue:
(1) C -> AS: IDC ||PC || IDV
(2) AS -> C: Ticket
(3) C ->V: IDC ||Ticket
Ticket = E(Kv, [IDC ||ADC || IDV])
Cont.,
where
C = client
AS = authentication server
V = server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
Kv = secret encryption key shared by AS and V
Contd.,
In this scenario, the user logs on to a workstation and requests access to server
V.
The client module C in the user’s workstation requests the user’s password and
then sends a message to the AS that includes the user’s ID, the server’s ID, and
the user’s password.
 The AS checks its database to see if the user has supplied the proper password
for this user ID and whether this user is permitted access to server V.
If both tests are passed, the AS accepts the user as authentic and must now
convince the server that this user is authentic.
To do so, the AS creates a ticket that contains the user’s ID and network
address and the server’s ID.
This ticket is encrypted using the secret key shared by the AS and this server.
This ticket is then sent back to C.
Because the ticket is encrypted, it cannot be altered by C or by an opponent.
Contd.,
With this ticket, C can now apply to V for service.
C sends a message to V containing C’s ID and the ticket.
V decrypts the ticket and verifies that the user ID in the
ticket is the same as the unencrypted user ID in the
message.
If these two match, the server considers the user
authenticated and grants the requested service.
A More Secure Authentication Dialogue
Although the foregoing scenario solves some of the problems of
authentication in an open network environment, problems remain.
Two in particular stand out. First, we would like to minimize the
number of times that a user has to enter a password.
However, under this scheme, it remains the case that a user would
need a new ticket for every different service.
 If a user wished to access a print server, a mail server, a file
server, and so on, the first instance of each access would require a
new ticket and hence require the user to enter the password.
The second problem is that the earlier scenario involved a
plaintext transmission of the password [message (1)]. An
eavesdropper could capture the password and use any service
accessible to the victim.
Contd.,
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 (but still hypothetical) scenario is as follows.
Contd.,
The new service, TGS, issues tickets to users who have
been authenticated to AS.
 Thus, the user first requests a ticket-granting ticket
(Tickettgs) from the AS.
The client module in the user workstation saves this ticket.
Each time the user requires access to a new service, the
client applies to the TGS, using the ticket to authenticate
itself.
The TGS then grants a ticket for the particular service.
The client saves each service-granting ticket and uses it to
authenticate its user to a server each time a particular
service is requested.
Contd.,
1. The client requests a ticket-granting ticket on behalf of the
user by sending its user’s ID to the AS, together with the
TGS ID, indicating a request to use the TGS service.
2. The AS responds with a ticket that is encrypted with a key
that is derived from the user’s password (Kc), which is
already stored at the AS.
When this response arrives at the client, the client prompts
the user for his or her password, generates the key, and
attempts to decrypt the incoming message.
If the correct password is supplied, the ticket is successfully
recovered.
Contd.,
Now that the client has a ticket-granting ticket, access to any server
can be obtained with steps 3 and 4.
3. The client requests a service-granting ticket on behalf of the user.
For this purpose, the client transmits a message to the TGS
containing the user’s ID, the ID of the desired service, and the
ticket-granting ticket.
4. The TGS decrypts the incoming ticket using a key shared only by
the AS and the TGS (Ktgs) and verifies the success of the decryption
by the presence of its ID.
It checks to make sure that the lifetime has not expired.
Then it compares the user ID and network address with the incoming
information to authenticate the user.
If the user is permitted access to the server V, the TGS issues a ticket
to grant access to the requested service.
Contd.,
Finally, with a particular service-granting ticket, the client
can gain access to the corresponding service with step 5.
5. The client requests access to a service on behalf of the
user.
For this purpose, the client transmits a message to the
server containing the user’s ID and the service granting
ticket.
The server authenticates by using the contents of the
ticket.
Kerberos Realms and Multiple Kerberi
A full-service Kerberos environment consisting of a Kerberos
server, a number of clients, and a number of application servers
requires the following:
1. The Kerberos server must have the user ID and hashed
passwords of all participating users in its database.
 All users are registered with the Kerberos server.
2. The Kerberos server must share a secret key with each server.
 All servers are registered with the Kerberos server.
Such an environment is referred to as a Kerberos realm.
The concept of realm can be explained as follows.
A Kerberos realm is a set of managed nodes that share the
same Kerberos database.
Contd.,
The Kerberos database resides on the Kerberos master computer
system, which should be kept in a physically secure room.
A read only copy of the Kerberos database might also reside on
other Kerberos computer systems.
However, all changes to the database must be made on the
master computer system.
Changing or accessing the contents of a Kerberos database
requires the Kerberos master password.
A related concept is that of a Kerberos principal, which is a
service or user that is known to the Kerberos system.
Each Kerberos principal is identified by its principal name.
Principal names consist of three parts: a service or user name, an
instance name, and a realm name.
Contd.,
Two realms to support interrealm authentication, a third
requirement is added:
3. 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.
The scheme requires that the Kerberos server in one realm
trust the Kerberos server in the other realm to authenticate
its users.
Contd,.
With these ground rules in place, we can describe the
mechanism as follows (Figure 15.3):
A user wishing service on a server in another realm needs
a ticket for that server.
The user’s client follows the usual procedures to gain
access to the local TGS and then requests a ticket-granting
ticket for a remote TGS (TGS in another realm).
The client can then apply to the remote TGS for a service-
granting ticket for the desired server in the realm of the
remote TGS.
Contd.,
The details of the exchanges illustrated in Figure 15.3 are
as follows (compare Table 15.1).
Kerberos version 5
Kerberos version 5 is specified in RFC 4120 and provides a
number of improvements over version 4.
To begin, we provide an overview of the changes from
version 4 to version 5 and then look at the version 5
protocol.
Differences between Versions 4 and 5 Version 5 is intended
to address the limitations of version 4 in two areas:
environmental shortcomings and technical deficiencies.
Kerberos version 4 was developed for use within the Project
Athena environment and, accordingly, did not fully address
the need to be of general purpose.
This led to the following environmental shortcomings.
Environmental Shortcomings
1. Encryption system dependence: Version 4 requires the
use of DES.
Export restriction on DES as well as doubts about the
strength of DES were thus of concern.
In version 5, ciphertext is tagged with an encryption-type
identifier so that any encryption technique may be used.
Encryption keys are tagged with a type and a length,
allowing the same key to be used in different algorithms
and allowing the specification of different variations on a
given algorithm.
Contd.,
2. Internet protocol dependence: Version 4 requires the use of
Internet Protocol (IP) addresses.
Other address types, such as the ISO network address, are not
accommodated.
Version 5 network addresses are tagged with type and length,
allowing any network address type to be used.
3. Message byte ordering: In version 4, the sender of a message
employs a byte ordering of its own choosing and tags the message
to indicate least significant byte in lowest address or most
significant byte in lowest address.
This techniques works but does not follow established conventions.
In version 5, all message structures are defined using Abstract
Syntax Notation One (ASN.1) and Basic Encoding Rules (BER),
which provide an unambiguous byte ordering.
Contd.,
4. Ticket lifetime: Lifetime values in version 4 are
encoded in an 8-bit quantity in units of five minutes.
Thus, the maximum lifetime that can be expressed is 28 *
5 = 1280 minutes (a little over 21 hours).
This may be inadequate for some applications (e.g., a
long-running simulation that requires valid Kerberos
credentials throughout execution).
In version 5, tickets include an explicit start time and end
time, allowing tickets with arbitrary lifetimes.
Contd.,
5. Authentication forwarding: Version 4 does not allow
credentials issued to one client to be forwarded to some
other host and used by some other client.
This capability would enable a client to access a server and
have that server access another server on behalf of the
client.
For example, a client issues a request to a print server that
then accesses the client’s file from a file server, using the
client’s credentials for access. Version 5 provides this
capability
Contd.,
6. Interrealm authentication: In version 4,
interoperability among N realms requires on the order of
N2 Kerberos-to-Kerberos relationships, as described
earlier.
 Version 5 supports a method that requires fewer
relationships, as Described shortly.
Contd.,
 Apart from these environmental limitations, there are technical def
 1. Double encryption: Note in Table 15.1 [messages (2) and (4)]
that tickets provided to clients are encrypted twice — once with the
secret key of the target server and then again with a secret key
known to the client.
 The second encryption is not necessary and is computationally
wasteful.
 2. PCBC encryption: Encryption in version 4 makes use of a
nonstandard mode of DES known as propagating cipher block
chaining (PCBC).
 It has been demonstrated that this mode is vulnerable to an attack
involving the interchange of ciphertext blocks.
 PCBC was intended to provide an integrity check as part of the
encryption operation.
 Version 5 provides explicit integrity mechanisms, allowing the
Contd.,
3. Session keys: Each ticket includes a session key that is used by
the client to encrypt the authenticator sent to the service associated
with that ticket.
In addition, the session key may subsequently be used by the client
and the server to protect messages passed during that session.
However, because the same ticket may be used repeatedly to gain
service from a particular server, there is the risk that an opponent
will replay messages from an old session to the client or the server.
In version 5, it is possible for a client and server to negotiate a
subsession key, which is to be used only for that one connection.
A new access by the client would result in the use of a new
subsession key
Contd.,
4. Password attacks: Both versions are vulnerable to a
password attack.
The message from the AS to the client includes material
encrypted with a key based on the client’s password.
 An opponent can capture this message and attempt to decrypt
it by trying various passwords.
If the result of a test decryption is of the proper form, then the
opponent has discovered the client’s password and may
subsequently use it to gain authentication credentials from
Kerberos.
Version 5 does provide a mechanism known as
preauthentication, which should make password attacks more
difficult, but it does not prevent them.
The Version 5 Authentication Dialogue
The Version 5 Authentication Dialogue Table 15.3
summarizes the basic version 5 dialogue.
This is best explained by comparison with version 4 (Table
15.1).
Contd.,
First, consider the authentication service exchange. Message (1) is a
client request for a ticket-granting ticket.
As before, it includes the ID of the user and the TGS.
The following new elements are added:
• Realm: Indicates realm of user
• Options: Used to request that certain flags be set in the returned ticket
• Times: Used by the client to request the following time settings in the
ticket:
—from: the desired start time for the requested ticket
—till: the requested expiration time for the requested ticket
—rtime: requested renew-till time
• Nonce: A random value to be repeated in message (2) to assure that
the response is fresh and has not been replayed by an opponent