[Review Request: Kerberos5] handbook security chapter review

[Tillman Hodgson]

On Sun, Aug 24, 2003 at 01:11:44PM +0200, Martin Heinen wrote:
> 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).

Thanks for reviewing it. I'll respond in-line to only the non markup
comments (as Tom is /much/ better at that than I am ;-) ).

> > +    <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).

Would reference to an outside reference (the MIT glossary, for example)
work?

I could also incorporate the glossary I wrote for ROSPA (pages 16 and 17
of http://www.rospa.ca/projects/kerberos/Heimdal_Kerberos.pdf). It's
probably too wordy though.

> > +    <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".

We should move all the Kerberos realms to EXAMPLE.ORG as well then.

> > +    <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>

I'd add:

"... when setting up <application>Kerberos</application> even if you
intend to run it internally."

(As an aside, ROSPA (a user group/professional association) runs a VPN
tunnel network. It connects multiple internal networks which means we
had to deal with realm name collisions issues).

> > +	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?

Probably more accurate too, as authorization does actually provide the
capability of performing actions (services do that).

> > +    <para>In order to reach the widest audience, these instructions assume
> > +	the use of the Heimdal distribution included in &os;.</para>

<snip>

> This section tells nothing new and should be removed.

I think it's important to note that we're using the Heimdal in the base
OS. MIT is more common by far in North America and the base Heimdal
doesn't include all the applications and daemons that the full Heimdal
package does.

I would install a Kerberos system differently if I wasn't using the base
Heimdal, for example.

> > +    <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.

That's true. I think it's a leftover in my conversion of
the document from -STABLE to -CURRENT. It's not needed in -CURRENT.

> > +	<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.

No, it doesn't. My intent was to ensure that users new to Kerberos get
in the habit of transferring everything securely so that they don't have
to figure out when it's safe not to. Drawing that line at "anything key
related" and dropping the secure instructions for krb5.conf might work
as well.

> > +	  <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>.

Definitely for isntances of /etc/krb5.keytab. I was using "keytab" in
it's generic sense here ... does that still qualify for <filename>
treatment?

I think there is a need for a generic term. For example, on the ROSPA
web server there is also a keytab in /usr/local/etc/apache/ (for use
with mod_auth_kerb). Several other daemons also liek their own keytab
and special keytabs are commonly used for Kerberos authenticated cron
jobs.

> > +	  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).

Can we reuse the wording from the krb5.conf section?

> > +	  <command>telnetd</command> man page for more details.</para>
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   &man.telnetd.8;


Oh, that's how that's done. Neat.

> > +	<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>
> 
> How about:
> 
>   Client applications such as <command>telnet</command>
>   usually do not require a user name or a principal.</para>

They still require a user /account/, though. I'd like to make that
unambiguous. Is there better wording to stress that?

> > +	<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
> 
> I don't know if everyone is familar with sudo.  The
> file .k5login is similar to .rhosts, which is well known.

.hosts above should definitely say .rhosts. Removing the reference to
sudo would mean rewording the "combination" aspect and replacing it with
something else like:

<para>The <filename>.k5login</filename> and
<filename>.k5users</filename> files, placed in a users home directory,
can be used in a similar fashion to <filename>.rhosts</filename>. They
can also provide fine-grained authorization beyond what
<filename>.rhosts</filename> provides. For example, if a ...

> > +	  <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>

Is it worth adding that the number of minutes of "drift" that is allowed
can be controlled by the krb5.conf "clockskew" setting?

> Time synchronization and ticket lifetimes were discussed
> in "Troubleshooting".  How about one section "Tips and
> Troubleshooting"?

I'm not positive that those sections overlap nicely.

For example, if authentication fails discovering that clockskew can
cause that is troubleshooting. Recommending that NTP be used to prevent
that isn't.

It coudl be made to work if all the tips were worded such that expressed
the negative ("long ticket lifetimes don't work", etc), but that might
be awkward.

> > +	  <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?

It's opposed to /home/user/tmp, which is a great way to solve the
problem of easily read tickets when stored on disk.

> > +	  <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!

True enough. The whole question of securing your backups isn't even
touched on in this document :-)

Thanks for your comments!

-T


-- 
"Everything you are against weakens you. Everything you are for
empowers you."
	- Wayne Dyer (American Psychotherapist & Author)