os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add a new section on Kerberos5.

Browse source 
Submitted by:	Tillman Hodgson <tillman@seekingfire.com> (original version)
Reviewed by:	-doc
This commit is contained in:
Tom Rhodes 2003-09-08 18:14:48 +00:00
parent cc1f38618d
commit 57780decd8
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=18094
1 changed files with 739 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

738
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1920,6 +1920,744 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
<sect1 id="kerberos5">
<sect1info>
<authorgroup>
<author>
<firstname>Tillman</firstname>
<surname>Hodgson</surname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Mark</firstname>
<surname>Murray</surname>
<contrib>Based on a contribution by </contrib>
</author>
</authorgroup>
</sect1info>
<title><application>Kerberos5</application></title>
<para>Every &os; release beyond &os;-5.1 includes support
only for <application>Kerberos5</application>. Hence
<application>Kerberos5</application> is the only version
included, and its configuration is similar in many aspects
to that of <application>KerberosIV</application>. The following
information only applies to
<application>Kerberos5</application> in post &os;-5.0
releases. Users who wish to use the
<application>KerberosIV</application> package may install the
<filename role="package">security/krb4</filename> port.</para>
<para><application>Kerberos</application> is a network add-on
system/protocol that allows users to authenticate themselves
through the services of a secure server. Services such as remote
login, remote copy, secure inter-system file copying and other
high-risk tasks are made considerably safer and more
controllable.</para>
<para><application>Kerberos</application> can be described as an
identity-verifying proxy system. It can also be described as a
trusted third-party authentication system.
<application>Kerberos</application> provides only one
function &mdash; the secure authentication of users on the network.
It does not provide authorization functions (what users are
allowed to do) or auditing functions (what those users did).
After a client and server have used
<application>Kerberos</application> to prove their identity, they
can also encrypt all of their communications to assure privacy
and data integrity as they go about their business.</para>
<para>Therefore it is highly recommended that
<application>Kerberos</application> be used with other security
methods which provide authorization and audit services.</para>
<para>The following instructions can be used as a guide on how to set
up <application>Kerberos</application> as distributed for &os;.
However, you should refer to the relevant manual pages for a complete
description.</para>
<para>For purposes of demonstrating a <application>Kerberos</application>
installation, the various namespaces will be handled as follows:</para>
<itemizedlist>
<listitem>
<para>The <acronym>DNS</acronym> domain (<quote>zone</quote>)
will be EXAMPLE.ORG.</para>
</listitem>
<listitem>
<para>The <application>Kerberos</application> realm will be
EXAMPLE.ORG.</para>
</listitem>
</itemizedlist>
<note>
<para>Please use real domain names when setting up
<application>Kerberos</application> even if you intend to run
it internally. This avoids <acronym>DNS</acronym> problems
and assures inter-operation with other
<application>Kerberos</application> realms.</para>
</note>
<sect2>
<title>History</title>
<para><application>Kerberos</application> was created by
<acronym>MIT</acronym> as a solution to network security problems.
The <application>Kerberos</application> protocol uses strong
cryptography so that a client can prove its identity to a server
(and vice versa) across an insecure network connection.</para>
<para><application>Kerberos</application> is both the name of a
network authentication protocol and an adjective to describe
programs that implement the program
(<application>Kerberos</application> telnet, for example). The
current version of the protocol is version 5, described in
<acronym>RFC</acronym>&nbsp;1510.</para>
<para>Several free implementations of this protocol are available,
covering a wide range of operating systems. The Massachusetts
Institute of Technology (<acronym>MIT</acronym>), where
<application>Kerberos</application> was originally developed,
continues to develop their <application>Kerberos</application>
package. It is commonly used in the <acronym>US</acronym>
as a cryptography product, as such it
has historically been affected by <acronym>US</acronym> export
regulations. The <acronym>MIT</acronym>
<application>Kerberos</application> is available as a port
(<filename role="package">security/krb5</filename>). Heimdal
<application>Kerberos</application> is another version 5
implementation, and was explicitly developed outside of the
<acronym>US</acronym> to avoid export
regulations (and is thus often included in non-commercial &unix;
variants). The Heimdal <application>Kerberos</application>
distribution is available as a port
(<filename role="package">security/heimdal</filename>), and a
minimal installation of it is included in the base &os;
install.</para>
<para>In order to reach the widest audience, these instructions assume
the use of the Heimdal distribution included in &os;.</para>
</sect2>
<sect2>
<title>Setting up a Heimdal <acronym>KDC</acronym></title>
<para>The Key Distribution Center (<acronym>KDC</acronym>) is the
centralized authentication service that
<application>Kerberos</application> provides &mdash; it is the
computer that issues <application>Kerberos</application> tickets.
The <acronym>KDC</acronym> is considered <quote>trusted</quote> by
all other computers in the <application>Kerberos</application>
realm, and thus has heightened security concerns.</para>
<para>Note that while running the <application>Kerberos</application>
server requires very few computing resources, a dedicated machine
acting only as a <acronym>KDC</acronym> is recommended for security
reasons.</para>
<para>To begin setting up a <acronym>KDC</acronym>, ensure that your
<filename>/etc/rc.conf</filename> file contains the correct
settings to act as a <acronym>KDC</acronym> (you may need to adjust
paths to reflect your own system):</para>
<programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
kerberos_stash="YES"</programlisting>
<note>
<para>The <option>kerberos_stash</option> is only available in
&os; 4.X.</para>
</note>
<para>Next we will set up your <application>Kerberos</application>
config file, <filename>/etc/krb5.conf</filename>:</para>
<programlisting>[libdefaults]
default_realm = EXAMPLE.ORG
[realms]
EXAMPLE.ORG = {
kdc = kerberos.EXAMPLE.ORG
}
[domain_realm]
.EXAMPLE.ORG = EXAMPLE.ORG</programlisting>
<para>Note that this <filename>/etc/krb5.conf</filename> file implies
that your <acronym>KDC</acronym> will have the fully-qualified
hostname of <hostid role="fqdn">kerberos.EXAMPLE.ORG</hostid>.
You will need to add a CNAME (alias) entry to your zone file to
accomplish this if your <acronym>KDC</acronym> has a different
hostname.</para>
<note>
<para>For large networks with a properly configured
<acronym>BIND</acronym> <acronym>DNS</acronym> server, the
above example could be trimmed to:</para>
<programlisting>[libdefaults]
default_realm = example.org</programlisting>
<para>With the following lines being appended to the
<hostid role="fqdn">example.org</hostid> zonefile:</para>
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.
_kerberos IN TXT EXAMPLE.ORG.</programlisting></note>
<para>Next we will create the <application>Kerberos</application>
database. This database contains the keys of all principals encrypted
with a master password. You are not
required to remember this password, it will be stored in a file
(<filename>/var/heimdal/m-key</filename>). To create the master
key, run <command>kstash</command> and enter a password.</para>
<para>Once the master key has been created, you can initialize the
database using the <command>kadmin</command> program with the
<literal>-l</literal> option (standing for <quote>local</quote>).
This option instructs <command>kadmin</command> to modify the
database files directly rather than going through the
<command>kadmind</command> network service. This handles the
chicken-and-egg problem of trying to connect to the database
before it is created. Once you have the <command>kadmin</command>
prompt, use the <command>init</command> command to create your
realms initial database.</para>
<para>Lastly, while still in <command>kadmin</command>, create your
first principal using the <command>add</command> command. Stick
to the defaults options for the principal for now, you can always
change them later with the <command>modify</command> command.
Note that you can use the <literal>?</literal> command at any
prompt to see the available options.</para>
<para>A sample database creation session is shown below:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>
&prompt.root; <userinput>kadmin -l</userinput>
kadmin> <userinput>init EXAMPLE.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin> <userinput>add tillman</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
<para>Now it's time to start up the <acronym>KDC</acronym> services.
Run <command>/etc/rc.d/kerberos start</command> and
<command>/etc/rc.d/kadmind start</command> to bring up the
services. Note that you won't have any Kerberized daemons running
at this point but you should be able to confirm the that the
<acronym>KDC</acronym> is functioning by obtaining and listing a
ticket for the principal (user) that you just created from the
command-line of the <acronym>KDC</acronym> itself:</para>
<screen>&prompt.user;<userinput>k5init <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password:
&prompt.user;<userinput>k5list</userinput>
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
Principal: tillman@EXAMPLE.ORG
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
v4-ticket file: /tmp/tkt500
k5list: No ticket file (tf_util)</screen>
</sect2>
<sect2>
<title><application>Kerberos</application> enabling a server with
Heimdal services</title>
<para>First, we need a copy of the <application>Kerberos</application>
configuration file, <filename>/etc/krb5.conf</filename>. To do
so, simply copy it over to the client computer from the
<acronym>KDC</acronym> in a secure fashion (using network utilities,
such as &man.scp.1;, or physically via a
floppy disk).</para>
<para>Next you need a <filename>/etc/krb5.keytab</filename> file.
This is the major difference between a server providing
<application>Kerberos</application> enabled daemons and a
workstation &mdash; the server must have a
<filename>keytab</filename> file. This file
contains the servers host key, which allows it and the
<acronym>KDC</acronym> 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.
This explicitly means that transferring it via a clear text
channel, such as <acronym>FTP</acronym>, is a very bad idea.</para>
<para>Typically, you transfer to the <filename>keytab</filename>
to the server using the <command>kadmin</command> program.
This is handy because you also need to create the host principal
(the <acronym>KDC</acronym> end of the
<filename>krb5.keytab</filename>) using
<command>kadmin</command>.</para>
<para>Note that you must have already obtained a ticket and that this
ticket must be allowed to use the <command>kadmin</command>
interface in the <filename>kadmind.acl</filename>. See the section
titled <quote>Remote administration</quote> in the Heimdal info
pages (<command>info heimdal</command>) for details on designing
access control lists. If you do not want to enable remote
<command>kadmin</command> access, you can simply securely connect
to the <acronym>KDC</acronym> (via local console,
&man.ssh.1; or <application>Kerberos</application>
&man.telnet.1;) and perform administration locally
using <command>kadmin -l</command>.</para>
<para>After installing the <filename>/etc/krb5.conf</filename> file,
you can use <command>kadmin</command> from the
<application>Kerberos</application> server. The
<command>add --random-key</command> command will let you add the
servers host principal, and the <command>ext</command> command
will allow you to extract the servers host principal to its own
keytab. For example:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> add --random-key host/myserver.EXAMPLE.ORG</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin><userinput> ext host/myserver.EXAMPLE.ORG</userinput>
kadmin><userinput> exit</userinput></screen>
<para>Note that the <command>ext</command> command (short for
<quote>extract</quote>) stores the extracted key in
<filename>/etc/krb5.keytab</filename> by default.</para>
<para>If you do not have <command>kadmind</command> running on the
<acronym>KDC</acronym> (possibly for security reasons) and thus
do not have access to <command>kadmin</command> remotely, you
can add the host principal
(<username>host/myserver.EXAMPLE.ORG</username>) directly on the
<acronym>KDC</acronym> and then extract it to a temporary file
(to avoid over-writing the <filename>/etc/krb5.keytab</filename>
on the <acronym>KDC</acronym>) using something like this:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
kadmin><userinput> exit</userinput></screen>
<para>You can then securely copy the keytab to the server
computer (using <command>scp</command> or a floppy, for
example). Be sure to specify a non-default keytab name
to avoid over-writing the keytab on the
<acronym>KDC</acronym>.</para>
<para>At this point your server can communicate with the
<acronym>KDC</acronym> (due to it's <filename>krb5.conf</filename>
file) and it can prove it's own identity (due to the
<filename>krb5.keytab</filename> file). It's now ready for
you to enable some <application>Kerberos</application> services.
For this example we will enable the <command>telnet</command>
service by putting a line like this into your
<filename>/etc/inetd.conf</filename> and then restarting the
&man.inetd.8; service with
<command>/etc/rc.d/inetd restart</command>:</para>
<programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting>
<para>The critical bit is that the <command>-a</command>
(for authentication) type is set to user. Consult for the
&man.telnetd.8; manual page for more details.</para>
</sect2>
<sect2>
<title><application>Kerberos</application> enabling a client with Heimdal</title>
<para>Setting up a client computer is almost trivially easy. As
far as <application>Kerberos</application> configuration goes,
you only need the <application>Kerberos</application>
configuration file, located at <filename>/etc/krb5.conf</filename>.
Simply securely copy it over to the client computer from the
<acronym>KDC</acronym>.</para>
<para>Test your client computer by attempting to use
<command>kinit</command>, <command>klist</command> and
<command>kdestroy</command> from the client to obtain, show, and
then delete a ticket for the principal you created above. You
should also be able to use <application>Kerberos</application>
applications to connect to <application>Kerberos</application>
enabled servers, though if that does not work and obtaining a
ticket does the problem is likely with the server and not with
the client or the <acronym>KDC</acronym>.</para>
<para>When testing an application like <command>telnet</command>,
try using a packet sniffer (such as &man.tcpdump.1;)
to confirm that your password is not sent in the clear. Try
using <command>telnet</command> with the <literal>-x</literal>
option, which encrypts the entire data stream (similar to
<command>ssh</command>).</para>
<para>The core <application>Kerberos</application> client applications
(traditionally named <command>kinit</command>,
<command>klist</command>, <command>kdestroy</command> and
<command>kpasswd</command>) are installed in
the base &os; install. Note that &os; versions prior to 5.0
renamed them to <command>k5init</command>,
<command>k5list</command>, <command>k5destroy</command>,
<command>k5passwd</command>, and <command>kstash</command>
(though it's typically only used once).</para>
<para>Various non-core <application>Kerberos</application> client
applications are also installed by default. This is where the
<quote>minimal</quote> nature of the base Heimdal installation is
felt: <command>telnet</command> is the only
<application>Kerberos</application> enabled service.</para>
<para>The Heimdal port adds some of the missing client applications:
<application>Kerberos</application> enabled versions of
<command>ftp</command>, <command>rsh</command>,
<command>rcp</command>, <command>rlogin</command>, and a few
other less common programs. The <acronym>MIT</acronym> port also
contains a full suite of <application>Kerberos</application>
client applications.</para>
</sect2>
<sect2>
<title>User configuration files: <filename>.k5login</filename> and <filename>.k5users</filename></title>
<para>Users within a realm typically have their
<application>Kerberos</application> principal (such as
<username>tillman@EXAMPLE.ORG</username>) mapped to a local
user account (such as a local account named
<username>tillman</username>). Client applications such as
<command>telnet</command> usually do not require a user name
or a principal.</para>
<para>Occasionally, however, you want to grant access to a local
user account to someone who does not have a matching
<application>Kerberos</application> principal. For example,
<username>tillman@EXAMPLE.ORG</username> may need access to the
local user account <username>webdevelopers</username>. Other
principals may also need access to that local account.</para>
<para>The <filename>.k5login</filename> and
<filename>.k5users</filename> files, placed in a users home
directory, can be used similar to a powerful combination of
<filename>.hosts</filename> and <filename>.rhosts</filename>,
solving this problem. For example, if a
<filename>.k5login</filename> with the following
contents:</para>
<screen>tillman@example.org
jdoe@example.org</screen>
<para>Were to be placed into the home directory of the local user
<username>webdevelopers</username> then both principals listed
would have access to that account without requiring a shared
password.</para>
<para>Reading the man pages for these commands is recommended.
Note that the <command>ksu</command> man page covers
<filename>.k5users</filename>.</para>
</sect2>
<sect2>
<title><application>Kerberos</application> Tips, Tricks, and Troubleshooting</title>
<itemizedlist>
<listitem>
<para>When using either the Heimdal or <acronym>MIT</acronym>
<application>Kerberos</application> ports ensure that your
<envar>PATH</envar> environment variable lists the
<application>Kerberos</application> versions of the client
applications before the system versions.</para>
</listitem>
<listitem>
<para>Is your time in sync? Are you sure? If the time is not in
sync (typically within five minutes) authentication will
fail.</para>
</listitem>
<listitem>
<para><acronym>MIT</acronym> and Heimdal inter-operate nicely.
Except for <command>kadmin</command>, the protocol for
which is not standardized.</para>
</listitem>
<listitem>
<para>If you change your hostname, you also need to change your
<username>host/</username> principal and update your keytab.
This also applies to special keytab entries like the
<username>www/</username> principal used for Apache's
<filename role="package">www/mod_auth_kerb</filename>.</para>
</listitem>
<listitem>
<para>All hosts in your realm must be resolvable (both forwards
and reverse) in <acronym>DNS</acronym> (or
<filename>/etc/hosts</filename> as a minimum). CNAMEs
will work, but the A and PTR records must be correct and in
place. The error message isn't very intuitive:
<errorname>Kerberos5 refuses authentication because Read req
failed: Key table entry not found</errorname>.</para>
</listitem>
<listitem>
<para>Some operating systems that may being acting as clients
to your <acronym>KDC</acronym> do not set the permissions
for <command>ksu</command> to be setuid
<username>root</username>. This means that
<command>ksu</command> does not work, which is a good
security idea but annoying. This is not a
<acronym>KDC</acronym> error.</para>
</listitem>
<listitem>
<para>With <acronym>MIT</acronym>
<application>Kerberos</application>, if you want to allow a
principal to have a ticket life longer than the default ten
hours, you must use <command>modify_principal</command> in
<command>kadmin</command> to change the maxlife of both the
principal in question and the <username>krbtgt</username>
principal. Then the principal can use the
<literal>-l</literal> option with <command>kinit</command>
to request a ticket with a longer lifetime.</para>
</listitem>
<listitem>
<note><para>If you run a packet sniffer on your
<acronym>KDC</acronym> to add in troubleshooting and then
run <command>kinit</command> from a workstation, you will
notice that your <acronym>TGT</acronym> is sent
immediately upon running <command>kinit</command> &mdash;
even before you type your password! The explanation is
that the <application>Kerberos</application> server freely
transmits a <acronym>TGT</acronym> (Ticket Granting
Ticket) to any unauthorized request; however, every
<acronym>TGT</acronym> is encrypted in a key derived from
the user's password. Therefore, when a user types their
password it is not being sent to the <acronym>KDC</acronym>,
it's being used to decrypt the <acronym>TGT</acronym> that
<command>kinit</command> already obtained. If the decryption
process results in a valid ticket with a valid time stamp,
the user has valid <application>Kerberos</application>
credentials. These credentials include a session key for
establishing secure communications with the
<application>Kerberos</application> server in the future, as
well as the actual ticket-granting ticket, which is actually
encrypted with the <application>Kerberos</application>
server's own key. This second layer of encryption is
unknown to the user, but it's what allows the
<application>Kerberos</application> server to verify
the authenticity of each <acronym>TGT</acronym>.</para></note>
</listitem>
<listitem>
<para>You have to keep the time in sync between all the
computers in your realm. <acronym>NTP</acronym> is
perfect for this. For more information on
<acronym>NTP</acronym>, see
<xref linkend="network-ntp">.</para>
</listitem>
<listitem>
<para>If you want to use long ticket lifetimes (a week, for
example) and you are using <application>OpenSSH</application>
to connect to the machine where your ticket is stored, make
sure that <application>Kerberos</application>
<option>TicketCleanup</option> is set to <literal>no</literal>
in your <filename>sshd_config</filename> or else your tickets
will be deleted when you log out.</para>
</listitem>
<listitem>
<para>Remember that host principals can have a longer ticket
lifetime as well. If your user principal has a lifetime of a
week but the host you are connecting to has a lifetime of nine
hours, you will have an expired host principal in your cache
and the ticket cache will not work as expected.</para>
</listitem>
<listitem>
<para>When setting up a <filename>krb5.dict</filename> file to
prevent specific bad passwords from being used (the manual page
for <command>kadmind</command> covers this briefly), remember
that it only applies to principals that have a password policy
assigned to them. The <filename>krb5.dict</filename> files
format is simple: one string per line. Creating a symbolic
link to <filename>/usr/share/dict/words</filename> might be
useful.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Differences with the <acronym>MIT</acronym> port</title>
<para>The major difference between the <acronym>MIT</acronym>
and Heimdal installs relates to the <command>kadmin</command>
program which has a different (but equivalent) set of commands
and uses a different protocol. This has a large implications
if your <acronym>KDC</acronym> is <acronym>MIT</acronym> as you
will not be able to use the Heimdal <command>kadmin</command>
program to administer your <acronym>KDC</acronym> remotely
(or vice versa, for that matter).</para>
<para>The client applications may also take slightly different
command line options to accomplish the same tasks. Following
the instructions on the <acronym>MIT</acronym>
<application>Kerberos</application> web site
(<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>)
is recommended. Be careful of path issues: the
<acronym>MIT</acronym> port installs into
<filename>/usr/local/</filename> by default, and the
<quote>normal</quote> system applications may be run instead
of <acronym>MIT</acronym> if your <envar>PATH</envar>
environment variable lists the system directories first.</para>
<note><para>With the <acronym>MIT</acronym>
<filename role="package">security/krb5</filename> port
that is provided by &os;, be sure to read the
<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
file installed by the port if you want to understand why logins
via <command>telnetd</command> and <command>klogind</command>
behave somewhat oddly. Most importantly, correcting the
<quote>incorrect permissions on cache file</quote> behavior
requires that the <command>login.krb5</command> binary be used
for authentication so that it can properly change ownership for
the forwarded credentials.</para></note>
</sect2>
<sect2>
<title>Mitigating limitations found in <application>Kerberos</application></title>
<sect3>
<title><application>Kerberos</application> is an all-or-nothing approach</title>
<para>Every service enabled on the network must be modified to
work with <application>Kerberos</application> (or be otherwise
secured against network attacks) or else the users credentials
could be stolen and re-used. An example of this would be
<application>Kerberos</application> enabling all remote shells
(via <command>rsh</command> and <command>telnet</command>, for
example) but not converting the <acronym>POP3</acronym> mail
server which sends passwords in plaintext.</para>
</sect3>
<sect3>
<title><application>Kerberos</application> is intended for single-user workstations</title>
<para>In a multi-user environment,
<application>Kerberos</application> is less secure.
This is because it stores the tickets in the
<filename>/tmp</filename> directory, which is readable by all
users. If a user is sharing a computer with several other
people simultaneously (i.e. multi-user), it is possible that
the user's tickets can be stolen (copied) by another
user.</para>
<para>This can be overcome with the <literal>-c</literal>
filename command-line option or (preferably) the
<envar>KRB5CCNAME</envar> environment variable, but this
is rarely done. In principal, storing the ticket in the users
home directory and using simple file permissions can mitigate
this problem.</para>
</sect3>
<sect3>
<title>The KDC is a single point of failure</title>
<para>By design, the <acronym>KDC</acronym> must be as secure as
the master password database is contained on it. The
<acronym>KDC</acronym> should have absolutely no other
services running on it and should be physically secured. The
danger is high because <application>Kerberos</application>
stores all passwords encrypted with the same key (the
<quote>master</quote> key), which in turn is stored as a file
on the <acronym>KDC</acronym>.</para>
<para>As a side note, a compromised master key is not quite as
bad as one might normally fear. The master key is only used
to encrypt the <application>Kerberos</application> database
and as a seed for the random number generator. As long as
access to your <acronym>KDC</acronym> is secure, an attacker
cannot do much with the master key.</para>
<para>Additionally, if the <acronym>KDC</acronym> is unavailable
(perhaps due to a denial of service attack or network problems)
the network services are unusable as authentication can not be
performed, a recipe for a denial-of-service attack. This can
alleviated with multiple <acronym>KDC</acronym>s (a single
master and one or more slaves) and with careful implementation
of secondary or fall-back authentication
(<acronym>PAM</acronym> is excellent for this).</para>
</sect3>
<sect3>
<title><application>Kerberos</application> Shortcomings</title>
<para><application>Kerberos</application> allows users, hosts
and services to authenticate between themselves. It does not
have a mechanism to authenticate the <acronym>KDC</acronym>
to the users, hosts or services. This means that a trojanned
<command>kinit</command> (for example) could record all user
names and passwords. Something like
<filename role="package">security/tripwire</filename> or
other file system integrity checking tools can alleviate
this.</para>
</sect3>
</sect2>
<sect2>
<title>Resources and further information</title>
<itemizedlist>
<listitem>
<para><ulink
url="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html">
The Kerberos FAQ</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://web.mit.edu/Kerberos/www/dialogue.html">Designing
an Authentication System: a Dialogue in Four Scenes</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510,
The <application>Kerberos</application> Network Authentication Service
(V5)</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://web.mit.edu/Kerberos/www/"><acronym>MIT</acronym>
<application>Kerberos</application> home page</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.pdc.kth.se/heimdal/">Heimdal
<application>Kerberos</application> home page</ulink></para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="firewalls">
<sect1info>
<authorgroup>