[Review Request: Kerberos5] handbook security chapter review

Tom Rhodes trhodes at FreeBSD.org
Sat Aug 23 13:52:26 UTC 2003


Greetings,

Here I bring the kerberos5 handbook section to everyone for review.
A few tidbits of pre-review information:

This was done under the theory that KerberosIV is gone from 5.1 and
post releases.  Thus there is a history part, and some extra information;
this was done so that we can fade away the other chapter with ease.
If it is desired for some unknown reason, I would like to commit the
entire part and then in a seperate commit: remove the
history/introduction.  This method would allow myself, or another
doc hacker to restore that information when the old version is
dissolved.

I will kill my whitespace lines before the commit, these are
here for 'markers' so that I would not get lost during my initial
copy-paste merge.  Please ignore them.

This was submitted to me in plain text, thus I did 95% of the
mark up.  All mistakes are mine and should be pointed out to
me.  I plan to commit this on Monday, or even Sunday night EST
if I get enough review.  Thanks!

-- 
Tom Rhodes


--- chapter.old	Sat Aug 23 08:11:30 2003
+++ chapter.sgml	Sat Aug 23 09:21:11 2003
@@ -106,7 +106,7 @@
       servers – meaning that external entities can connect and talk
       to them.  As yesterday's mini-computers and mainframes become
       today's desktops, and as computers become networked and
-      internetworked, security becomes an even bigger issue.</para>
+      inter-networked, security becomes an even bigger issue.</para>
 
     <para>Security is best implemented through a layered
       <quote>onion</quote> approach.  In a nutshell, what you want to do is
@@ -1919,6 +1919,740 @@
 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 should only apply to
+      <application>Kerberos5</application> in post &os;-5.0
+      releases.</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.</para>
+
+    <para>Note that <application>Kerberos</application> provides only
+      authentication services and nothing more.  Therefore it is highly
+      recommended that <application>Kerberos</application> be used with
+      other security methods which 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 namespaceswill be handled as follows:</para>
+
+    <itemizedList>
+      <listitem>
+	<para>The DNS domain (<quote>zone</quote>) will be example.prv.</para>
+      </listitem>
+
+      <listitem>
+	<para>The <application>Kerberos</application> realm will be
+	  EXAMPLE.PRV.</para>
+      </listitem>
+    </itemizedList>
+
+    <para>Please refrain from the use of these namespaces in the real
+      world.  Not only will it not be optimal for your network and
+      <acronym>DNS</acronym> server, it will make interoperating with other
+      <application>Kerberos</application> realms more difficult.</para>
+
+    <sect2>
+      <title>Background: 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> provides only one
+	function -- the secure authentication of users on the network.  It
+	does not provide authorization functions (what those users are
+	able to perform) or auditing fuctions (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><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> 1510.  <application>Kerberos</application>
+	was designed to provide strong authentication for client/server
+	applications (such as traditional Internet services like
+	<acronym>FTP</acronym> and telnet) by using secret-key
+	cryptography.</para>
+
+      <para>Several free implementations of this protocol are available,
+	covering a wide range of operating systems.  The Massachusetts
+	Institute of Technology, where <application>Kerberos</application>
+	was originally developed, continues to develop their
+	<application>Kerberos</application> package and it is commonly used
+	in the <acronym>US</acronym> (as a cryptography product, 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>Background: <application>KerberosIV</application> and
+        <application>Kerberos</application> 5</title>
+
+    <para>Older versions of <application>Kerberos</application> included both
+	<application>KerberosIV</application> (eBones) and
+	<application>Kerberos 5</application> (Heimdal).  Support for
+	<application>KerberosIV</application> has been dropped as of &os;
+	5.0.</para>
+
+    </sect2>
+
+    <sect2>
+      <title>Setting up a Heimdal <acronym>KDC</acronym></title>
+
+      <para>The <acronym>KDC</acronym>, or Key Distribution Center, is the
+	centralized authentication service that
+	<application>Kerberos</application> provides -- 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 <acronym>Kerberos</acronym> 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>
+
+      <para>Next we'll set up your <application>Kerberos</application>
+	config file, <filename>/etc/krb5.conf</filename>:</para>
+
+      <programlisting>[libdefaults]
+    default_realm = EXAMPLE.PRV
+[realms]
+    EXAMPLE.PRV = {
+        kdc = <application>Kerberos</application>.example.prv
+    }
+[domain_realm]
+    .example.prv = EXAMPLE.PRV</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>Kerberos.example.prv</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>
+
+      <para>Next we will create the <application>Kerberos</application>
+	database.  The keys of all the principals are stored in this
+	database in encrypted form 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
+	<command>-l</command> 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 <literal>kadmin></literal>
+	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 <command>?</command> command at any
+	prompt to see the available options are.</para>
+
+      <para>A sample database creation session is shown below:</para>
+
+      <programlisting>&prompt.root;kstash
+Master key: xxxxxxxx
+Verifying password - Master key: xxxxxxxx
+
+&prompt.root;kadmin -l
+kadmin> init EXAMPLE.PRV
+Realm max ticket life [unlimited]:
+kadmin> add tillman
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+Password: xxxxxxxx
+Verifying password - Password: xxxxxxxx</programlisting>
+
+      <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>
+
+      <programlisting>&prompt.user;k5init tillman
+tillman at EXAMPLE.PRV's Password:
+
+&prompt.user;k5list
+Credentials cache: FILE:/tmp/krb5cc_500
+        Principal: tillman at EXAMPLE.PRV
+
+  Issued           Expires          Principal
+Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.PRV at EXAMPLE.PRV
+Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.PRV at EXAMPLE.PRV
+
+v4-ticket file: /tmp/tkt500
+k5list: No ticket file (tf_util)</programlisting>
+
+      </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 the network,
+	  such as <command>scp</command>, or physically via a
+	  floppy).</para>
+
+	<para>Next you need a <filename>/etc/krb5.keytab</filename> file.
+	  This is the major difference between a server provide
+	  <application>Kerberos</application> enabled daemons and a
+	  workstation -- the server must have a keytab 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 keytab 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,
+	  <command>ssh</command> or <application>Kerberos</application>
+	  <command>telnet</command>) 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>
+
+	<programlisting>&prompt.root;kadmin
+kadmin> add --random-key host/myserver.example.prv
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+kadmin> ext host/myserver.example.prv
+kadmin> exit</programlisting>
+
+	<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, which is
+	  handy.</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.prv</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>
+
+	<programlisting>&prompt.root;kadmin
+kadmin> ext --keytab=/tmp/example.keytab host/myserver.smithclan.prv
+kadmin> exit</programlisting>
+
+	<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
+	  <command>inetd</command> 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
+	  <command>telnetd</command> man 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 to use <application>Kerberos</application>
+	  applications to connect to <application>Kerberos</application>
+	  enabled servers, though if that doesn't 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 <command>tcpdump</command>)
+	  to confirm that your password is not sent in the clear.  Try
+	  using <command>telnet</command> with the <command>-x</command>
+	  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 config file: .k5login and .k5users</title>
+
+	<para>Users within a realm typically have their
+	  <application>Kerberos</application> principal (such as
+	  <username>tillman at EXAMPLE.PRV</username>) mapped to a local
+	  user account (such as a local account named
+	  <username>tillman</username>).  This well as the user account
+	  usually does not have to be specified when using a client
+	  application such as <command>telnet</command>.</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 at EXAMPLE.PRV</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 <command>sudo</command>, solving
+	  this problem. For example, if a <filename>.k5login</filename>
+	  with the following contents:</para>
+
+	<programlisting>tillman at EXAMPLE.PRV
+jdoe at EXAMPLE.PRV</programlisting>
+
+	<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>Troubleshooting</title>
+
+	<itemizedlist>
+	  <listitem>
+	    <para>When using either the Heimdal or <acronym>MIT</acronym>
+	      <application>Kerberos</application> ports ensure that your
+	      <literal>PATH</literal> 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 often
+	      fails.</para>
+	  </listitem>
+
+	  <listitem>
+	    <para><acronym>MIT</acronym>and Heimdal interoperate 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
+	      <application>mod_auth_kerb</application>.</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:
+	      <quote>KerberosV5 refuses authentication because Read req
+	      failed: Key table entry not found</quote>.</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_prinicpal</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
+	      <option>-l</option> option with <command>kinit</command>
+	      to request a ticket with a longer life.</para>
+	  </listitem>
+	</itemizedlist>
+
+	<para>Note: 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> -- even before you type your
+	  password!  The explanation is that the
+	  <application>Kerberos</application> server freely transmits a
+	  <acronym>TGT</acronym> 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>
+
+      </sect2>
+
+      <sect2>
+	<title><application>Kerberos</application> Tips</title>
+
+	<itemizedlist>
+
+	<listitem>
+	  <para>You have to keep the time in sync between all the
+	    computers in your realm.  <acronym>NTP</acronym> is
+	    perfect for this.</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
+	    life as well.  If your user principal has a lifetime of a
+	    week but the host you're 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 man 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 symlink to
+	  <filename>/usr/share/dict/words</filename> might be
+	  useful.</para>
+	</listitem>
+      </itemizedlist>
+
+      </sect2>
+
+      <sect2>
+	<title>Differences with the MIT port</title>
+
+	<para>The major differences 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 <literal>PATH</literal>
+	  environment variable lists the system directories first.</para>
+
+	<para>Important note: With the <acronym>MIT</acronym> krb5 port
+	  that is provided by &os;, be sure and 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 chown the forwarded
+	  credentials.</para>
+
+      </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 global
+	    <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 <command>-c</command>
+	    filename command-line option or (preferably) the
+	    <literal>KRB5CCNAME</literal> 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 security failure</title>
+
+	  <para>By design, the <acronym>KDC</acronym> must be 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 <application>KDC</application>.</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 denail-of-service attack.  This can
+	    alleviated with multiple <acronym>KDCs</acronym> (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 trojaned
+	    <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>



More information about the freebsd-doc mailing list