ECS401: Cryptography and

Network Security

Module 5: Authentication Protocols

Lecture 45
Outline of the lecture
• Kerberos Version 4 Overview
• Kerberos Version 5 Overview
• The Version 5 Authentication Dialogue

2
Kerberos
Version 4
Overview

3
Kerberos Version 4 Overview
Table 1: Summary of Kerberos Version 4 Message Exchanges

4
Kerberos Version 4 Overview

 where,

5
Kerberos Version 4 Overview
Table 2: Rationale for the Elements of the Kerberos Version 4 Protocol

6
Kerberos
Version 4
Overview

7
(b) Ticket-Granting Service Exchange
Kerberos Version 4 Overview

(b) Ticket-Granting Service Exchange

8
Kerberos
Version 4
Overview

9
(c) Client/Server Authentication Exchange
 Table 3: Summary of Kerberos Version 5 Message Exchanges
Kerberos
Version 5
Overview

10
Comparison between Kerberos Version 4 and 5
Table 1: Summary of Kerberos Version 4 Message Exchanges Table 3: Summary of Kerberos Version 5 Message Exchanges

11
The Version 5 Authentication Dialogue
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:

• Times: Used by
the client to request • Nonce: A random
the following time value to be repeated
• Options: Used to settings in the ticket: in message (2) to
• Realm: Indicates request that certain • —from: the desired start assure that the
time for the requested
realm of user flags be set in the ticket
response is fresh
returned ticket • —till: the requested and has not been
expiration time for the replayed by an
requested ticket opponent
• —rtime: requested
renew-till time

12
The Version 5 Authentication Dialogue
Message (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.

This 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 information.

The 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. These flags introduce significant
new functionality to version 5.

13
The Version 5 Authentication Dialogue
In addition, version Finally, for the
Let us now compare Message (4) has the
5 includes requested client/server
the ticket-granting same structure as
times and options authentication
service exchange for message (2). It
for the ticket and a exchange, several
versions 4 and 5. We returns a ticket plus
nonce—all with new features appear
see that message (3) information needed
functions similar to in version 5. In
for both versions by the client, with
those of message message (5), the
includes an the information
(1). The client may request
authenticator, a encrypted using the
authenticator itself as an option that
ticket, and the name session key now
is essentially the mutual
of the requested shared by the client
same as the one authentication is
service. and the TGS.
used in version 4. required.

Version 4 Version 5 14
The Version 5 Authentication Dialogue
The authenticator includes several new fields:

Sequence number: An optional field

Subkey: The client’s choice for an
that specifies the starting sequence
encryption key to be used to protect
number to be used by the server for
this specific application session. If this
messages sent to the client during this
field is omitted, the session key from
session. Messages may be sequence
the ticket is used.
numbered to detect replays.

15
 The Version 5 Authentication Dialogue
If mutual
authentication is
required, the server
responds with message The subkey field, if
(6). This message present, overrides the
includes the timestamp subkey field, if present,
from the authenticator. in message (5).

Note that in version 4, the The optional sequence

timestamp was incremented by one. number field specifies
This is not necessary in version 5, the starting sequence
because the nature of the format of number to be used by
messages is such that it is not the client.
possible for an opponent to create
message (6) without knowledge of
the appropriate encryption keys.

16
Version 4 Version 5
The Version 5 Authentication Dialogue
Ticket Flags

The flags field included in tickets in version 5 supports expanded functionality compared to that
available in version 4. Table 4 summarizes the flags that may be included in a ticket.

The INITIAL flag indicates that this ticket was issued by the AS, not by the TGS. When a client requests
a service-granting ticket from the TGS, it presents a ticket-granting ticket obtained from the AS. In
version 4, this was the only way to obtain a service-granting ticket.
Version 5 provides the additional capability that the client can get a service-granting ticket directly
from the AS. The utility of this is as follows: A server, such as a password-changing server, may wish to
know that the client’s password was recently tested.
The PRE-AUTHENT flag, if set, indicates that when the AS received the initial request [message (1)], it
authenticated the client before issuing a ticket. The exact form of this pre-authentication is left
unspecified.

17
 The Version 5 Authentication Dialogue
Ticket Flags

18
Table 4: Kerberos Version 5 Flags
The Version 5 Authentication Dialogue
Ticket Flags

The AS decrypts the block

When a user wants to get a
and will not send a ticket-
ticket, it has to send to the AS
As an example, the MIT granting ticket back unless
a pre-authentication block
implementation of version 5 the timestamp in the pre-
containing a random
has encrypted timestamp authentication block is within
confounder, a version
pre-authentication, enabled the allowable time skew
number, and a timestamp all
by default. (time interval to account for
encrypted in the client’s
clock drift and network
password-based key.
delays).

19
The Version 5 Authentication Dialogue
Ticket Flags Another possibility is the use of a smart card that generates continually changing passwords that are
included in the pre-authenticated messages.

The passwords generated by the card can be based on a user’s password but be transformed by the
card so that, in effect, arbitrary passwords are used. This prevents an attack based on easily guessed
passwords. If a smart card or similar device was used, this is indicated by the HW-AUTHENT flag.

When a ticket has a long lifetime, there is the potential for it to be stolen and used by an opponent
for a considerable period. If a short lifetime is used to lessen the threat, then overhead is involved in
acquiring new tickets.

In the case of a ticket granting ticket, the client would either have to store the user’s secret key, which
is clearly risky, or repeatedly ask the user for a password. 20
The Version 5 Authentication Dialogue
Ticket Flags

A client can have the ticket

A compromise scheme is the A client may request that the
renewed by presenting it to
use of renewable tickets. A AS provide a ticket-granting
the TGS with a requested new
ticket with the RENEWABLE The advantage of this ticket with the MAY-
expiration time. If the new
flag set includes two mechanism is that the TGS POSTDATE flag set. The client
time is within the limit of the
expiration times: one for this may refuse to renew a ticket can then use this ticket to
latest permissible value, the
specific ticket and one that is reported as stolen. request a ticket that is flagged
TGS can issue a new ticket
the latest permissible value as POSTDATED and INVALID
with a new session time and a
for an expiration time. from the TGS.
later specific expiration time.

21
The Version 5 Authentication Dialogue
Ticket Flags

Subsequently, the
client may submit the The client can obtain a When the execution
With this approach,
postdated ticket for number of tickets for reaches a point in time
the client does not
validation. This this session at once, when a new ticket is
have to repeatedly use
scheme can be useful with spread out time required, the client
its ticket-granting
for running a long values. All but the first can get the
ticket to obtain a
batch job on a server ticket are initially appropriate ticket
service-granting ticket.
that requires a ticket invalid. validated.
periodically.

22
The Version 5 Authentication Dialogue
Ticket Flags

The proxy concept is a

This ticket then can be
limited case of the
presented to a remote
more powerful For example, realms
TGS. This capability
forwarding procedure. could be structured
allows a client to gain Each step of the walk
If a ticket is set with hierarchically. Then a
access to a server on would involve
the FORWARDABLE client could walk up
another realm without forwarding a ticket-
flag, a TGS can issue to the tree to a common
requiring that each granting ticket to the
the requestor a ticket- node and then back
Kerberos maintain a next TGS in the path.
granting ticket with a down to reach a target
secret key with
different network realm.
Kerberos servers in
address and the
every other realm.
FORWARDED flag set.

23
The Version 5 Authentication Dialogue
Ticket Flags In version 5, it is possible for a server to act as a proxy
on behalf of a client, in effect adopting the
credentials and privileges of the client to request a
service from another server. If a client wishes to use
this mechanism, it requests a ticket-granting ticket
with the PROXIABLE flag set.

When this ticket is presented to the TGS, the TGS is

permitted to issue a service-granting ticket with a
different network address; this latter ticket will have
its PROXY flag set.

An application receiving such a ticket may accept it or

require additional authentication to provide an audit
trail.

24
The Version 5 Authentication Dialogue
Ticket Flags

If a ticket is set This capability For example,

with the allows a client to realms could be
FORWARDABLE gain access to a structured
The proxy concept flag, a TGS can Each step of the
server on another hierarchically.
is a limited case of walk would
issue to the realm without Then a client
the more requestor a ticket- involve forwarding
requiring that could walk up the
powerful granting ticket a ticket-granting
each Kerberos tree to a common
forwarding with a different ticket to the next
maintain a secret node and then
procedure. network address TGS in the path.
key with Kerberos back down to
and the servers in every reach a target
FORWARDED flag other realm. realm.
set. This ticket
then can be
presented to a
remote TGS.

25