Datasheet

“main” (Installation and Administration) — 2004/6/25 — 13:29 — page 660 — #686
i
i
i
i
i
i
i
i
the names both of the client and the ticket-granting server
the current time
a lifetime assigned to this ticket
the client’s IP address
the newly-generated session key
This ticket is then sent back to the client together with the session key,
again in encrypted form, but this time the private key of the client is
used. This private key is only known to Kerberos and the client, be-
cause it is derived from your user password. Now that the client has
received this response, you are prompted for your password. This
password is converted into the key that can decrypt the package sent
by the authentication server. The package is “unwrapped” and pass-
word and key are erased from the workstation’s memory. As long as
the lifetime given to the ticket used to obtain other tickets does not
expire, your workstation can prove your identity.
Requesting a Service To request a service from any server in the network,
the client application needs to prove its identity to the server. There-
fore, the application generates an authenticator. An authenticator con-
sists of the following components:
the client’s principal
the client’s IP address
the current time
a checksum (chosen by the client)
All this information is encrypted using the session key that the client
has already received for this special server. The authenticator and the
ticket for the server are sent to the server. The server uses its copy of
the session key to decrypt the authenticator, which gives it all infor-
mation needed about the client requesting its service to compare it
to that contained in the ticket. The server checks if the ticket and the
authenticator originate from the same client.
Without any security measures implemented on the server side, this
stage of the process would be an ideal target for replay attacks. Some-
one could try to resend a request stolen off the net some time before.
To prevent this, the server does not accept any request with a time
stamp and ticket received previously. In addition to that, a request
with a time stamp differing too much from the time the request is re-
ceived can be ignored.
660 26.5. Network Authentication — Kerberos