Figure : Kerberos Version 4 Message Exchange Scenario
Step – 1: The
client sends a message to the AS requesting access to the TGS. It includes a
timestamp, so that the AS knows that the message is timely.
Step – 2: The AS
responds with a message, encrypted with a key derived from the user’s password
(KC), that contains the ticket. The encrypted message also contains
a copy of the session key, KC, tgs, where the subscripts indicate
that this is a session key for C and TGS. Because this session key is inside
the message encrypted with KC, only the user’s client can read it.
The same session key is included in the ticket, which can be read only by the
TGS. Thus, the session key has been securely delivered to both C and the TGS.
Step – 3: C sends
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
C’s user and a timestamp. The TGS uses the session key to decrypt the
authenticator. The TGS can then check the name and 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 ticket’s real owner.
Step – 4: Reply
message from TGS is encrypted with KC, tgs and includes a session
key to be shared between C and the server V, the ID of V, and the timestamp of
the ticket. The ticket itself includes the same session key.
Step – 5: When C
sends ticket and an authenticator. The server can decrypt the ticket, recover
the session key, and decrypt the authenticator.
Step – 6: The server returns the value of the timestamp from the authenticator,
incremented by 1, and encrypted in the session key. C can decrypt this message
to recover the incremented timestamp. Because the message was encrypted by the
session key, C is assured that it could have been created only by V. The
contents of the message assure C that this is not a replay of an old reply.
Summery of Kerberos version 4 message exchange scenario
To learn more about Kerberos Version 4 message exchange, Click here
Kerberos:
Kerberos is a network authentication protocol that works on the basis of
tickets to allow nodes communicating over a non-secure network to prove their
identity to one another in a secure manner.
Different Version of Kerberos Protocols
Using Authentication Server (AS)
Step – 1: 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.
Step – 2: 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.
Step – 3: With
this ticket, C can now apply to V (Server) 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 matches, the server considers the user authenticated and grants the
requested service.
Problems:
Problem –
1:
Under this scheme, a user would need a new ticket for every different service.
If a user wants 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.
Problem –
2:
In this scheme, password is transmitted without encryption. An eavesdropper
could capture the password and use any service accessible to the victim.
Using Ticket Granting Server (TGS)
Step – 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.
Step – 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. Thus, we have used
the password to obtain credentials from Kerberos without having to transmit the
password in plaintext. Here, the opponent may be able to reuse the ticket to
spoof the TGS. To counter this, the ticket includes a timestamp, indicating the
date and time at which the ticket was issued, and a lifetime, indicating the
length of time for which the ticket is valid.
Step – 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.
Step – 4: The TGS
decrypts the incoming ticket using 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.
Step – 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.
Problems
Problem –
1:
A network service (the TGS or an application service) must be able to prove
that the person using a ticket is the same person to whom that ticket was
issued.
Problem –
2:
There may be a requirement for servers to authenticate themselves to users.
Without such authentication, the false server would then be in a position to
act as a real server and capture any information from the user and deny the
true service to the user.
Solution
AS
provides both the client and the TGS with a secret piece of information in a
secure manner. Then the client can prove its identity to the TGS by revealing
the secret information—again in a secure manner. An efficient way of accomplishing this is to
use an encryption key as the secure information; this is referred to as a
session key in Kerberos.
To learn more about Kerberos Version 4, Click here
