13.5.Â Kerberos

Contributed by TillmanHodgson.

Based on a contribution by MarkMurray.

Kerberos is a network
authentication protocol which was originally created by the
Massachusetts Institute of Technology (MIT)
as a way to securely provide authentication across a potentially
hostile network. The Kerberos
protocol uses strong cryptography so that both a client and
server can prove their identity without sending any unencrypted
secrets over the network. Kerberos
can be described as an identity-verifying proxy system and as a
trusted third-party authentication system. After a user
authenticates with Kerberos, their
communications can be encrypted to assure privacy and data
integrity.

The only function of Kerberos is
to provide the secure authentication of users and servers on the
network. It does not provide authorization or auditing
functions. It is recommended that
Kerberos be used with other security
methods which provide authorization and audit services.

The current version of the protocol is version 5, described
in RFCÂ 4120. Several free
implementations of this protocol are available, covering a wide
range of operating systems. MIT continues to
develop their Kerberos package. It
is commonly used in the US as a cryptography
product, and has historically been subject to
US export regulations. In FreeBSD,
MITKerberos is
available as the security/krb5 package or
port. The Heimdal Kerberos
implementation was explicitly developed outside of the
US to avoid export regulations. The Heimdal
Kerberos distribution is included in
the base FreeBSD installation, and another distribution with more
configurable options is available as
security/heimdal in the Ports
Collection.

In Kerberos users and services
are identified as “principals” which are contained
within an administrative grouping, called a
“realm”. A typical user principal would be of the
form
user@REALM
(realms are traditionally uppercase).

This section provides a guide on how to set up
Kerberos using the Heimdal
distribution included in FreeBSD.

For purposes of demonstrating a
Kerberos installation, the name
spaces will be as follows:

The DNS domain (zone) will be
example.org.

The Kerberos realm will be
EXAMPLE.ORG.

Note:

Use real domain names when setting up
Kerberos, even if it will run
internally. This avoids DNS problems and
assures inter-operation with other
Kerberos realms.

13.5.1.Â Setting up a Heimdal KDC

The Key Distribution Center (KDC) is
the centralized authentication service that
Kerberos provides, the
“trusted third party” of the system. It is the
computer that issues Kerberos
tickets, which are used for clients to authenticate to
servers. Because the KDC is considered
trusted by all other computers in the
Kerberos realm, it has heightened
security concerns. Direct access to the KDC should be
limited.

While running a KDC requires few
computing resources, a dedicated machine acting only as a
KDC is recommended for security
reasons.

Note:

In order for clients to be able to find the
Kerberos services, they
must have either
a fully configured /etc/krb5.conf or a
minimally configured /etc/krb5.confand a properly configured
DNS server.

Next, create the Kerberos
database which contains the keys of all principals (users and
hosts) encrypted with a master password. It is not required
to remember this password as it will be stored in
/var/heimdal/m-key; it would be
reasonable to use a 45-character random password for this
purpose. To create the master key, run
kstash and enter a password:

Once the master key has been created, the database should
be initialized. The Kerberos
administrative tool kadmin(8) can be used on the KDC in a
mode that operates directly on the database, without using the
kadmind(8) network service, as
kadmin -l. This resolves the
chicken-and-egg problem of trying to connect to the database
before it is created. At the kadmin
prompt, use init to create the realm's
initial database:

Lastly, while still in kadmin, create
the first principal using add. Stick to
the default options for the principal for now, as these can be
changed later with modify. Type
? at the prompt to see the available
options.

Next, start the KDC services by running
service kdc start and
service kadmind start. While there will
not be any kerberized daemons running at this point, it is
possible to confirm that the KDC is
functioning by obtaining a ticket for the
principal that was just created:

13.5.2.Â Configuring a Server to Use
Kerberos

The first step in configuring a server to use
Kerberos authentication is to
ensure that it has the correct configuration in
/etc/krb5.conf. The version from the
KDC can be used as-is, or it can be
regenerated on the new system.

Next, create /etc/krb5.keytab on the
server. This is the main part of “Kerberizing” a
service — it corresponds to generating a secret shared
between the service and the KDC. The
secret is a cryptographic key, stored in a
“keytab”. The keytab contains the server's host
key, which allows it and the KDC to verify
each others' identity. It must be transmitted to the server
in a secure fashion, as the security of the server can be
broken if the key is made public. Typically, the
keytab is generated on an administrator's
trusted machine using kadmin, then securely
transferred to the server, e.g., with scp(1); it can also
be created directly on the server if that is consistent with
the desired security policy. It is very important that the
keytab is transmitted to the server in a secure fashion: if
the key is known by some other party, that party can
impersonate any user to the server! Using
kadmin on the server directly is
convenient, because the entry for the host principal in the
KDC database is also created using
kadmin.

Of course, kadmin is a kerberized
service; a Kerberos ticket is
needed to authenticate to the network service, but to ensure
that the user running kadmin is actually
present (and their session has not been hijacked),
kadmin will prompt for the password to get
a fresh ticket. The principal authenticating to the kadmin
service must be permitted to use the kadmin
interface, as specified in kadmind.acl.
See the section titled “Remote administration” in
info heimdal for details on designing
access control lists. Instead of enabling remote
kadmin access, the administrator could
securely connect to the KDC via the local
console or ssh(1), and perform administration locally
using kadmin -l.

After installing /etc/krb5.conf,
use add --random-key in
kadmin. This adds the server's host
principal to the database, but does not extract a copy of the
host principal key to a keytab. To generate the keytab, use
ext to extract the server's host principal
key to its own keytab:

Note that ext_keytab stores the
extracted key in /etc/krb5.keytab by
default. This is good when being run on the server being
kerberized, but the --keytab
path/to/file argument
should be used when the keytab is being extracted
elsewhere:

The keytab can then be securely copied to the server
using scp(1) or a removable media. Be sure to specify a
non-default keytab name to avoid inserting unneeded keys into
the system's keytab.

At this point, the server can read encrypted messages from
the KDC using its shared key, stored in
krb5.keytab. It is now ready for the
Kerberos-using services to be
enabled. One of the most common such services is
sshd(8), which supports
Kerberos via the
GSS-API. In
/etc/ssh/sshd_config, add the
line:

GSSAPIAuthentication yes

After making this change, sshd(8) must be restarted
for the new configuration to take effect:
service sshd restart.

13.5.3.Â Configuring a Client to Use
Kerberos

As it was for the server, the client requires
configuration in /etc/krb5.conf. Copy
the file in place (securely) or re-enter it as needed.

Test the client by using kinit,
klist, and kdestroy from
the client to obtain, show, and then delete a ticket for an
existing principal. Kerberos
applications should also be able to connect to
Kerberos enabled servers. If that
does not work but obtaining a ticket does, the problem is
likely with the server and not with the client or the
KDC. In the case of kerberized
ssh(1), GSS-API is disabled by
default, so test using ssh -o
GSSAPIAuthentication=yes
hostname.

When testing a Kerberized application, try using a packet
sniffer such as tcpdump to confirm that no
sensitive information is sent in the clear.

Various Kerberos client
applications are available. With the advent of a bridge so
that applications using SASL for
authentication can use GSS-API mechanisms
as well, large classes of client applications can use
Kerberos for authentication, from
Jabber clients to IMAP clients.

Users within a realm typically have their
Kerberos principal mapped to a
local user account. Occasionally, one needs to grant access
to a local user account to someone who does not have a
matching Kerberos principal. For
example, tillman@EXAMPLE.ORG may need
access to the local user account webdevelopers. Other
principals may also need access to that local account.

The .k5login and
.k5users files, placed in a user's home
directory, can be used to solve this problem. For example, if
the following .k5login is placed in the
home directory of webdevelopers, both principals
listed will have access to that account without requiring a
shared password:

13.5.4.Â MIT Differences

The major difference between the MIT
and Heimdal implementations is that kadmin
has a different, but equivalent, set of commands and uses a
different protocol. If the KDC is
MIT, the Heimdal version of
kadmin cannot be used to administer the
KDC remotely, and vice versa.

Client applications may also use slightly different
command line options to accomplish the same tasks. Following
the instructions at http://web.mit.edu/Kerberos/www/
is recommended. Be careful of path issues: the
MIT port installs into
/usr/local/ by default, and the FreeBSD
system applications run instead of the
MIT versions if PATH lists
the system directories first.

When using MIT Kerberos as a KDC on
FreeBSD, the following edits should also be made to
rc.conf:

If the hostname is changed, the host/ principal must be
changed and the keytab updated. This also applies to
special keytab entries like the HTTP/ principal used for
Apache's www/mod_auth_kerb.

All hosts in the realm must be both forward and
reverse resolvable in DNS or, at a
minimum, exist in /etc/hosts. CNAMEs
will work, but the A and PTR records must be correct and
in place. The error message for unresolvable hosts is not
intuitive: Kerberos5 refuses authentication
because Read req failed: Key table entry not
found.

Some operating systems that act as clients to the
KDC do not set the permissions for
ksu to be setuid root. This means that
ksu does not work. This is a
permissions problem, not a KDC
error.

With MITKerberos, to allow a principal
to have a ticket life longer than the default lifetime of
ten hours, use modify_principal at the
kadmin(8) prompt to change the
maxlife of both the principal in
question and the
krbtgt
principal. The principal can then use
kinit -l to request a ticket with a
longer lifetime.

When running a packet sniffer on the
KDC to aid in troubleshooting while
running kinit from a workstation, the
Ticket Granting Ticket (TGT) is sent
immediately, even before the password is typed. This is
because the Kerberos server
freely transmits a TGT to any
unauthorized request. However, every
TGT is encrypted in a key derived from
the user's password. When a user types their password, it
is not sent to the KDC, it is instead
used to decrypt the TGT that
kinit already obtained. If the
decryption process results in a valid ticket with a valid
time stamp, the user has valid
Kerberos credentials. These
credentials include a session key for establishing secure
communications with the
Kerberos server in the future,
as well as the actual TGT, which is
encrypted with the Kerberos
server's own key. This second layer of encryption allows
the Kerberos server to verify
the authenticity of each TGT.

Host principals can have a longer ticket lifetime. If
the user principal has a lifetime of a week but the host
being connected to has a lifetime of nine hours, the user
cache will have an expired host principal and the ticket
cache will not work as expected.

When setting up krb5.dict to
prevent specific bad passwords from being used as
described in kadmind(8), remember that it only
applies to principals that have a password policy assigned
to them. The format used in
krb5.dict is one string per line.
Creating a symbolic link to
/usr/share/dict/words might be
useful.

13.5.6.Â Mitigating Kerberos
Limitations

Since Kerberos is an all or
nothing approach, every service enabled on the network must
either be modified to work with
Kerberos or be otherwise secured
against network attacks. This is to prevent user credentials
from being stolen and re-used. An example is when
Kerberos is enabled on all remote
shells but the non-Kerberized POP3 mail
server sends passwords in plain text.

The KDC is a single point of failure.
By design, the KDC must be as secure as its
master password database. The KDC should
have absolutely no other services running on it and should be
physically secure. The danger is high because
Kerberos stores all passwords
encrypted with the same master key which is stored as a file
on the KDC.

A compromised master key is not quite as bad as one might
fear. The master key is only used to encrypt the
Kerberos database and as a seed for
the random number generator. As long as access to the
KDC is secure, an attacker cannot do much
with the master key.

If the KDC is unavailable, network
services are unusable as authentication cannot be performed.
This can be alleviated with a single master
KDC and one or more slaves, and with
careful implementation of secondary or fall-back
authentication using PAM.

Kerberos allows users, hosts
and services to authenticate between themselves. It does not
have a mechanism to authenticate the
KDC to the users, hosts, or services. This
means that a trojanned kinit could record
all user names and passwords. File system integrity checking
tools like security/tripwire can
alleviate this.