Date: Thu, 4 Sep 2003 13:34:02 -0400 From: Tom Rhodes <trhodes@FreeBSD.org> To: FreeBSD-doc@FreeBSD.org Cc: Robert Watson <rwatson@FreeBSD.org> Subject: [Review Request]: Kerberos5 final draft Message-ID: <20030904133402.06da66da.trhodes@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
Greetings -doc team, Robert,
Please see the diff and give me feedback. This has already gone
through a good review on -doc so I'm only really waiting for Robert's
review. Although I want to get any final comments or "please commit's"
now.
Thanks!
--- chapter.sgml Thu Sep 4 13:12:30 2003
+++ chapter.new Thu Sep 4 13:19:05 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,7 +1919,746 @@
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 — 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 interoperation 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> 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 — 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">exmple.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</screen>
+
+ <screen>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</screen>
+
+ <screen>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 — 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;kadmin
+ kadmin> add --random-key host/myserver.EXAMPLE.ORG
+ Max ticket life [unlimited]:
+ Max renewable life [unlimited]:
+ Attributes []:
+ kadmin> ext host/myserver.EXAMPLE.ORG
+ kadmin> exit</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;kadmin
+ kadmin> ext --keytab=/tmp/example.keytab host/myserver.smithclan.prv
+ kadmin> exit</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 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
+ <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>KerberosV5 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> —
+ 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 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>
<authorgroup>
--
Tom Rhodes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030904133402.06da66da.trhodes>