Kerbero V4 Authentication
Dialogue Message Exchange
additional problems remain in the more secure authentication dialogue:
associated with the ticket granting ticket. If the lifetime is very short, then
the user will be repeatedly asked for a password. If the lifetime is long, then
the opponent has the greater opportunity for replay.
hRequirement for the servers to authenticate themselves to users.
actual Kerberos protocol version 4 is as follows :
third-party authentication scheme
Authentication Server (AS)
initially negotiate with AS to identify self
provides a non-corruptible authentication credential (ticket granting ticket
Ticket Granting server (TGS)
subsequently request access to other services from TGS on basis of users TGT
1 Kerberos Realms and Multiple Kerberi
full-service Kerberos environment consisting of a Kerberos server, a number of
clients, and a
application servers requires the following:
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.
Kerberos server must share a secret key with each server. All servers are
registered with the Kerberos server.
environment is referred to as a Kerberos
The concept of realm
can be explained as follows.
Kerberos realm is a set of managed nodes that share the same Kerberos database.
The Kerberos database resides on the Kerberos master computer system, which
should be kept in a physically secure room.
read-only copy of the Kerberos database might also reside on other Kerberos
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
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.
scheme requires that the Kerberos server in one realm trust the Kerberos server
in the other realm to authenticate its users. Furthermore, the participating
servers in the second realm must also be willing to trust the Kerberos server
in the first realm.
2 Kerberos version 5
of Kerberos provides a number of improvements over version 4.
in mid 1990‟s
improvements over v4
as Internet standard RFC 151
Differences between version 4 and 5
is intended to address the limitations of version 4 in two areas:
system dependence o internet protocol dependence
message byte ordering
PCBC encryption o Session keys
The version 5 authentication dialogue
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:
Indicates realm of user
Used to request that certain flags be set in the returned ticket
Used by the client to request the following time settings in the ticket: from:
the desired start time for the requested ticket
requested expiration time for the requested ticket rtime: requested renew-till
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
(2) returns a ticket-granting ticket, identifying information for the client,
and a block encrypted using the encryption key based on the user's password.
block includes the session key to be used between the client and the TGS, times
specified in message (1), the nonce from message (1), and TGS identifying
ticket itself includes the session key, identifying information for the client,
the requested time values, and flags that reflect the status of this ticket and
the requested options.
flags introduce significant new functionality to version 5. For now, we defer a
discussion of these flags and concentrate on the overall structure of the
version 5 protocol.
now compare the ticket-granting service exchange for versions 4 and 5. We see
that message (3) for both versions includes an authenticator, a ticket, and the
name of the requested service.
addition, version 5 includes requested times and options for the ticket and a
nonce, all with functions similar to those of message (1).
authenticator itself is essentially the same as the one used in version 4.
(4) has the same structure as message (2), returning a ticket plus information
needed by the client, the latter encrypted with the session key now shared by
the client and the TGS.
for the client/server authentication exchange, several new features appear in
version 5. In message (5), the client may request as an option that mutual
authentication is required. The authenticator includes several new fields as
Subkey: The client's choice for an
encryption key to be used to protect this
application session. If this field is omitted, the session key from the ticket
(Kc,v) is used.
Sequence number: An optional field that
specifies the starting sequence number to be used by the server for messages sent to the client during this
session. Messages may be sequence numbered to detect replays.
authentication is required, the server responds with message (6). This message
includes the timestamp from the authenticator. Note that in version 4, the
timestamp was incremented by one. This is not necessary in version 5 because
the nature of the format of messages is such that it is not possible for an
opponent to create message (6) without knowledge of the appropriate encryption
field included in tickets in version 5 supports expanded functionality compared
to that available in version 4.