Datasheet

“main” (Installation and Administration) — 2004/6/25 — 13:29 — page 659 — #685
i
i
i
i
i
i
i
i
26
Security in the Network
realm — this specifies your Kerberos realm. Normally, your
realm is your domain name in uppercase letters.
mutual authentication Kerberos ensures that both client and server can
be sure of each others identity. They share a session key, which they
can use to communicate securely.
session key Session keys are temporary private keys generated by Ker-
beros. They are known to the client and used to encrypt the commu-
nication between the client and the server for which it requested and
received a ticket.
replay Almost all messages sent in a network can be eavesdropped,
stolen, and resent. In the Kerberos context, this would be most dan-
gerous if an attacker manages to obtain your request for a service con-
taining your ticket and authenticator. He could then try to resend it
(replay) to impersonate you. However, Kerberos implements several
mechanisms to deal with that problem.
server or service Service is used to refer to a specific action to perform. The
process behind this action is referred to as a server.
26.5.2 How Kerberos Works
Kerberos is often called a third party trusted authentication service, which
means all its clients trust Kerberos’s judgment of another client’s identity.
Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is worth all the trust put in it, run both the authentica-
tion and ticket-granting server on a dedicated machine. Make sure only the
administrator can access this machine physically and over the network. Re-
duce the (networking) services run on it to the absolute minimum — do not
even run sshd.
First Contact Your first contact with Kerberos is quite similar to any lo-
gin procedure at a normal networking system. Enter your user name.
This piece of information and the name of the ticket-granting service
are sent to the authentication server (Kerberos). If the authentication
server knows about your existence, it will generate a (random) ses-
sion key for further use between your client and the ticket-granting
server. Now the authentication server prepares a ticket for the ticket-
granting server. The ticket contains the following information — all
encrypted with a session key only the authentication server and the
ticket-granting server know:
659SUSE LINUX Enterprise Server