Date: Sun, 24 Aug 2003 13:11:44 +0200 From: Martin Heinen <martin@sumuk.de> To: Tom Rhodes <trhodes@freebsd.org> Cc: FreeBSD-doc@freebsd.org Subject: Re: [Review Request: Kerberos5] handbook security chapter review Message-ID: <20030824131144.A62111@sumuk.de> In-Reply-To: <20030823092754.1e3dc84c.trhodes@FreeBSD.org>; from trhodes@freebsd.org on Sat, Aug 23, 2003 at 09:27:54AM -0400 References: <20030823092754.1e3dc84c.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 23, 2003 at 09:27:54AM -0400, Tom Rhodes wrote:
> Greetings,
>
> Here I bring the kerberos5 handbook section to everyone for review.
Great, thanks to both of you. You will find my
suggestions inline. There are a lot of contractions
(you're) inside which need to be expanded (I did
not mark them all).
> 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!
This is a long patch to review, it took me
at least three runs :-)
> --- 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>
This would be a separate commit?
>
> <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>
[ ... ]
> + <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
^^^^^^^^^^^^^^^^^^^^
... applies only 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>
[1] (reference, see below)
The introduction should also explain the common
Kerberos buzzwords (e.g. tickets, principals).
> +
> + <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>
^^^^^^^^^^^^^^^^^^^
... which provide authorization
> +
> + <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>
^^^^^^^^^^^^^^
... namespaces will
> +
> + <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>
All domain names in examples should be "example.org".
> +
> + <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>
I would like to put this into a note and reformulate it a bit:
<note>
<para>Please use real domain names when setting up
<application>Kerberos</application>. This avoids
<acronym>DNS</acronym> problems and assures
interoperation with other <application>Kerberos</application>
realms.</para>
</note>
> +
> + <sect2>
> + <title>Background: History</title>
If history is background information, then there is no
need to state this:
<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> 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).
Maybe "what users are allowed to do" sounds better?
> + 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>
^
<acronym>RFC</acronym> 1510.
> + 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>
The purpose of Kerberos was already described above [1].
The last sentence could be removed.
> +
> + <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
Split this into two sentences?
package. <application>Kerberos</application> is commonly ...
> + 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
^^^^
UNIX or &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>
This section tells nothing new and should be removed.
> +
> + <sect2>
> + <title>Setting up a Heimdal <acronym>KDC</acronym></title>
> +
> + <para>The <acronym>KDC</acronym>, or Key Distribution Center, is the
The Key Distribution Center (<acronym>KDC</acronym>)
> + 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
^^^^^^^^^
<application>
> + 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>
Don't know exactly:
... kerberos5_server_enable="YES"
CURRENT does not have "Kerberos_stash" in /etc/defaults/rc.conf.
> +
> + <para>Next we'll set up your <application>Kerberos</application>
we will
> + config file, <filename>/etc/krb5.conf</filename>:</para>
> +
> + <programlisting>[libdefaults]
> + default_realm = EXAMPLE.PRV
> +[realms]
> + EXAMPLE.PRV = {
> + kdc = <application>Kerberos</application>.example.prv
^^^^^^^^^^^^^
I don't think we should markup to program listings.
The listings are provided as is.
> + }
> +[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
How about:
The database contains the keys of all principals encrypted
with a master password.
> + 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>
^
<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 <command>?</command> command at any
> + prompt to see the available options are.</para>
^^^^^
available options.</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>
This should be a screen element and entered text should
be marked up with <userinput> tags.
There should be space between the prompt and the command.
> +
> + <para>Now it's time to start up the <acronym>KDC</acronym> services.
^^^^
... it is
> + 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@EXAMPLE.PRV's Password:
> +
> +&prompt.user;k5list
> +Credentials cache: FILE:/tmp/krb5cc_500
> + Principal: tillman@EXAMPLE.PRV
> +
> + Issued Expires Principal
> +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV
> +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV
> +
> +v4-ticket file: /tmp/tkt500
> +k5list: No ticket file (tf_util)</programlisting>
This "screen shot" should use <screen> too.
> +
> + </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>
Does /etc/krb5.conf really need to be transfered in a
secure fashion? After all, it contains only information
which is already public.
> +
> + <para>Next you need a <filename>/etc/krb5.keytab</filename> file.
> + This is the major difference between a server provide
^^^^^^^
... providing
> + <application>Kerberos</application> enabled daemons and a
> + workstation -- the server must have a keytab file. This file
—
"keytab" and all further instances should probably be
marked up with <filename>keytab</filename>.
> + 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>
Instead of stating what not to do, it is better to
explain how to transfer the file in a secure fashion
(scp, floppy).
> +
> + <para>Typically, you transfer to the keytab to the server using the
^^^^^^^^^^^^^^^^^^^^
... transfer the <filename>keytab</filename> file to
> + <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>
> +
[ ... ]
> + <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>
<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, which is
> + handy.</para>
Delete "which is handy"
The example following proves that this is not handy :-)
> +
> + <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>
^^
Missing ".".
> +
> + <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
... It is now
> + 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>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
&man.telnetd.8;
> +
> + </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
^^^^^^^^
See above.
> + <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>
^^^^^
Missing "able".
> + applications to connect to <application>Kerberos</application>
> + enabled servers, though if that doesn't work and obtaining a
^^^^^^^
... does not
> + ticket does the problem is likely with the server and not with
> + the client or the <acronym>KDC</acronym>.</para>
[ ... ]
> + <sect2>
> + <title>User config file: .k5login and .k5users</title>
<filename>.k5login</filename> and <filename>.k5users</filename>
> +
> + <para>Users within a realm typically have their
> + <application>Kerberos</application> principal (such as
> + <username>tillman@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>
How about:
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.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
I don't know if everyone is familar with sudo. The
file .k5login is similar to .rhosts, which is well known.
> + this problem. For example, if a <filename>.k5login</filename>
> + with the following contents:</para>
[ ... ]
> + <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
^^^^^^^^^
<envar>
> + <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>
It will fail:
... minutes) authentication fails.</para>
> + </listitem>
> +
> + <listitem>
> + <para><acronym>MIT</acronym>and Heimdal interoperate nicely.
^^^
... </acronym> and
> + 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
^^^^^^^
<errorname> is for error messages.
> + 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
^^^^
lifetime
> + hours, you must use <command>modify_prinicpal</command> in
> + <command>kadmin</command> to change the maxlife of both the
<option>maxlife</option>
> + 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>
^^^^^
lifetime
> + </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,
Is "..." really needed here?
&ellip;
> + 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
it is ...
> + <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
it is ...
> + allows the <application>Kerberos</application> server to verify
> + the authenticity of each <acronym>TGT</acronym>.</para>
> +
> + </sect2>
> +
> + <sect2>
> + <title><application>Kerberos</application> Tips</title>
Time synchronization and ticket lifetimes were discussed
in "Troubleshooting". How about one section "Tips and
Troubleshooting"?
> +
> + <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
^^^^
... lifetime
> + 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
^^^^^^^^
manual page
> + <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
^^^^^^^
symbolic link
> + <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>
difference
> + 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>
<envar>
> + 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
<command>chown</command> does not seem to be a proper verb.
> + 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>
&ellip; if it is really needed here.
> +
> + </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
What is "global" about /tmp?
... in the <filename>/tmp</filename> directory
> + <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
<envar>
> + 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>
<title>The KDC is a single point of failure</title>
It's not only about security: If you loose the master database,
everything is lost!
> +
> + <para>By design, the <acronym>KDC</acronym> must be secure as
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 <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
<acronym>KDC</acronym>s
> + 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>
[ ... ]
--
Marxpitn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030824131144.A62111>