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

Technical review of the Kerberos chapter

Browse source 
Many of the statements in this chapter were just plain wrong.

Apply some major modernization, in particular the current Kerberos RFC is
4120, not 1510.  Kerberized telnet, rlogin, ftp and similar are no longer
recommended -- use ssh and scp instead.

The heimdal in base is no longer crippled so as to be a minimal installation;
it is fully functional.  The heimdal in ports does offer the option to install
some additional features such as KCM and PKINIT.

Add a bit more introduction to Kerberos terminology and conventions.

Make the sample output closer to the current reality.

Don't imply that eight characters is a particularly strong password.

security/krb5 does not install ktelnetd, klogind, and friends anymore,
so there's no need to mention its README.FreeBSD here (especially since
these things are disrecommended anyway).

www/mod_auth_kerb uses the HTTP/ principal, not the www/ principal.

Kerberized ssh uses GSSAPI these days, so the Kerberos-specific options
are not worth mentioning.

Kerberos works just fine on multiuser machines; the permissions of
credentials cache files are set to 0600.

Remove the section on access issues with kerberos and ssh; it is very
confused.  (It seems to be talking about ssh keys and ssh-agent, but
in a very unclear and inaccurate fashion.)

There is still more to be done here, but this should get us most of the way.

Reviewed by:	bcr (partial)
Approved by:	hrs (mentor)
This commit is contained in:
Benjamin Kaduk 2014-05-15 02:46:04 +00:00
parent 2d11188f36
commit 1d66b0ca66
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44840
1 changed files with 148 additions and 200 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

348
en_US.ISO8859-1/books/handbook/security/chapter.xml
View file

@ -1095,10 +1095,11 @@ sendmail : PARANOID : deny</programlisting>
<para><application>Kerberos</application> is a network <para><application>Kerberos</application> is a network
authentication protocol which was originally created by the authentication protocol which was originally created by the
Massachusetts Institute of Technology Massachusetts Institute of Technology
(<acronym>MIT</acronym>) as a solution to network security (<acronym>MIT</acronym>) as a way to securely provide authentication
problems. The <application>Kerberos</application> protocol uses across a potentially hostile network.
The <application>Kerberos</application> protocol uses
strong cryptography so that both a client and server can prove strong cryptography so that both a client and server can prove
their identity over an insecure network. their identity without sending any unencrypted secrets over the network.
<application>Kerberos</application> can be described as an <application>Kerberos</application> can be described as an
identity-verifying proxy system and as a trusted third-party identity-verifying proxy system and as a trusted third-party
authentication system. After a user authenticates with authentication system. After a user authenticates with
@ -1106,29 +1107,36 @@ sendmail : PARANOID : deny</programlisting>
encrypted to assure privacy and data integrity.</para> encrypted to assure privacy and data integrity.</para>
<para>The only function of <application>Kerberos</application> is <para>The only function of <application>Kerberos</application> is
to provide the secure authentication of users on the network. to provide the secure authentication of users and servers on the network.
It does not provide authorization or auditing functions. It is It does not provide authorization or auditing functions. It is
recommended that <application>Kerberos</application> be used recommended that <application>Kerberos</application> be used
with other security methods which provide authorization and with other security methods which provide authorization and
audit services.</para> audit services.</para>
<para>The current version of the protocol is version 5, described <para>The current version of the protocol is version 5, described
in <acronym>RFC</acronym>&nbsp;1510. Several free in <acronym>RFC</acronym>&nbsp;4120. Several free
implementations of this protocol are available, covering a wide implementations of this protocol are available, covering a wide
range of operating systems. <acronym>MIT</acronym> continues to range of operating systems. <acronym>MIT</acronym> continues to
develop their <application>Kerberos</application> package. It develop their <application>Kerberos</application> package. It
is commonly used in the <acronym>US</acronym> as a cryptography is commonly used in the <acronym>US</acronym> as a cryptography
product, and has historically been affected by product, and has historically been subject to
<acronym>US</acronym> export regulations. In &os;, <acronym>US</acronym> export regulations. In &os;,
<acronym>MIT</acronym> <application>Kerberos</application> is <acronym>MIT</acronym> <application>Kerberos</application> is
available as the <package>security/krb5</package> package or available as the <package>security/krb5</package> package or
port. Heimdal <application>Kerberos</application> was port. The Heimdal <application>Kerberos</application> implementation was
explicitly developed outside of the <acronym>US</acronym> to explicitly developed outside of the <acronym>US</acronym> to
avoid export regulations. The Heimdal avoid export regulations. The Heimdal
<application>Kerberos</application> distribution is available as <application>Kerberos</application> distribution is included in
the <package>security/heimdal</package> package or port, and a the base &os; installation, and another distribution with more
minimal installation is included in the base &os; configurable options is available as <package>security/heimdal</package>
install.</para> in the Ports Collection.</para>
<para>In <application>Kerberos</application> users and services are
identified as <quote>principals</quote> which are contained within
an administrative grouping, called a <quote>realm</quote>. A
typical user principal would be of the form
<literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal>
(realms are traditionally uppercase).</para>
<para>This section provides a guide on how to set up <para>This section provides a guide on how to set up
<application>Kerberos</application> using the Heimdal <application>Kerberos</application> using the Heimdal
@ -1169,12 +1177,14 @@ sendmail : PARANOID : deny</programlisting>
<para>The Key Distribution Center (<acronym>KDC</acronym>) is <para>The Key Distribution Center (<acronym>KDC</acronym>) is
the centralized authentication service that the centralized authentication service that
<application>Kerberos</application> provides. It is the <application>Kerberos</application> provides, the <quote>trusted
third party</quote> of the system. It is the
computer that issues <application>Kerberos</application> computer that issues <application>Kerberos</application>
tickets. The <acronym>KDC</acronym> is considered trusted by tickets, which are used for clients to authenticate to servers.
Because the <acronym>KDC</acronym> is considered trusted by
all other computers in the all other computers in the
<application>Kerberos</application> realm, and thus has <application>Kerberos</application> realm, it has heightened security
heightened security concerns.</para> concerns. Direct access to the KDC should be limited.</para>
<para>While running a <acronym>KDC</acronym> requires few <para>While running a <acronym>KDC</acronym> requires few
computing resources, a dedicated machine acting only as a computing resources, a dedicated machine acting only as a
@ -1202,20 +1212,23 @@ kadmind5_server_enable="YES"</programlisting>
<para>In this example, the <acronym>KDC</acronym> will use the <para>In this example, the <acronym>KDC</acronym> will use the
fully-qualified hostname <systemitem fully-qualified hostname <systemitem
class="fqdomainname">kerberos.example.org</systemitem>. Add class="fqdomainname">kerberos.example.org</systemitem>. The
a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym> hostname of the KDC must be resolvable in the
zone file if the <acronym>KDC</acronym> has a different <acronym>DNS</acronym>.</para>
hostname than that specified in
<filename>/etc/krb5.conf</filename>.</para>
<para>For large networks with a properly configured <para><application>Kerberos</application> can also use the
<acronym>DNS</acronym> server, the above example could be <acronym>DNS</acronym> to locate KDCs, instead of a
trimmed to:</para> <literal>[realms]</literal> section in
<filename>/etc/krb5.conf</filename>. For large organizations that
have their own <acronym>DNS</acronym> servers, the above example
could be trimmed to:</para>
<programlisting>[libdefaults] <programlisting>[libdefaults]
default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting> default_realm = <replaceable>EXAMPLE.ORG</replaceable>
[domain_realm]
<replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
<para>With the following lines being appended to the <para>With the following lines being included in the
<systemitem class="fqdomainname">example.org</systemitem> zone <systemitem class="fqdomainname">example.org</systemitem> zone
file:</para> file:</para>
@ -1227,8 +1240,8 @@ _kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programl
<note> <note>
<para>In order for clients to be able to find the <para>In order for clients to be able to find the
<application>Kerberos</application> services, the <application>Kerberos</application> services, they
<acronym>KDC</acronym> <emphasis>must</emphasis> have either <emphasis>must</emphasis> have either
a fully configured <filename>/etc/krb5.conf</filename> or a a fully configured <filename>/etc/krb5.conf</filename> or a
minimally configured <filename>/etc/krb5.conf</filename> minimally configured <filename>/etc/krb5.conf</filename>
<emphasis>and</emphasis> a properly configured <emphasis>and</emphasis> a properly configured
@ -1239,20 +1252,22 @@ _kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programl
database which contains the keys of all principals (users and database which contains the keys of all principals (users and
hosts) encrypted with a master password. It is not required hosts) encrypted with a master password. It is not required
to remember this password as it will be stored in to remember this password as it will be stored in
<filename>/var/heimdal/m-key</filename>. To create the master <filename>/var/heimdal/m-key</filename>; it would be reasonable to
key, run <command>kstash</command> and enter a use a 45-character random password for this purpose. To create the
master key, run <command>kstash</command> and enter a
password:</para> password:</para>
<screen>&prompt.root; <userinput>kstash</userinput> <screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput> Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
Verifying password - Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen> Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
<para>Once the master key has been created, initialize the <para>Once the master key has been created, the database should be
database using <command>kadmin -l</command>. This option initialized. The <application>Kerberos</application> administrative
instructs <command>kadmin</command> to modify the local tool &man.kadmin.8; can be used on the KDC in a mode that
database files directly rather than going through the operates directly on the database, without using the &man.kadmind.8;
&man.kadmind.8; network service. This handles the network service, as <command>kadmin -l</command>.
chicken-and-egg problem of trying to connect to the database This resolves the chicken-and-egg problem of trying to connect to
the database
before it is created. At the <command>kadmin</command> before it is created. At the <command>kadmin</command>
prompt, use <command>init</command> to create the realm's prompt, use <command>init</command> to create the realm's
initial database:</para> initial database:</para>
@ -1280,21 +1295,22 @@ Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></u
<command>service kadmind start</command>. While there will <command>service kadmind start</command>. While there will
not be any kerberized daemons running at this point, it is not be any kerberized daemons running at this point, it is
possible to confirm that the <acronym>KDC</acronym> is possible to confirm that the <acronym>KDC</acronym> is
functioning by obtaining and listing a ticket for the functioning by obtaining a ticket for the
principal that was just created from the command-line of the principal that was just created:</para>
<acronym>KDC</acronym>:</para>
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput> <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password: tillman@EXAMPLE.ORG's Password:
</screen>
&prompt.user; <userinput>klist</userinput> <para>Confirm that a ticket was successfully obtained using
Credentials cache: FILE:/tmp/krb5cc_500 <command>klist</command>:</para>
<screen>&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:/tmp/krb5cc_1001
Principal: tillman@EXAMPLE.ORG Principal: tillman@EXAMPLE.ORG
Issued Expires Principal Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen> Aug 27 15:37:58 2013 Aug 28 01:37:58 2013 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
<para>The temporary ticket can be revoked when the test is <para>The temporary ticket can be destroyed when the test is
finished:</para> finished:</para>
<screen>&prompt.user; <userinput>kdestroy</userinput></screen> <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
@ -1309,87 +1325,98 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
<secondary>enabling services</secondary> <secondary>enabling services</secondary>
</indexterm> </indexterm>
<para>To configure a server to use <para>The first step in configuring a server to use
<application>Kerberos</application> authentication, copy <application>Kerberos</application> authentication is to
<filename>/etc/krb5.conf</filename> from the ensure that it has the correct configuration in
<acronym>KDC</acronym> to the server in a secure fashion, such <filename>/etc/krb5.conf</filename>. The version from the
as &man.scp.1;, or physically via removable media.</para> <acronym>KDC</acronym> can be used as-is, or it can be
regenerated on the new system.</para>
<para>Next, create <filename>/etc/krb5.keytab</filename> on the <para>Next, create <filename>/etc/krb5.keytab</filename> on the
server. This is the major difference between a server server. This is the main part of <quote>Kerberizing</quote> a service
providing <application>Kerberos</application> enabled daemons &mdash; it corresponds to generating a secret shared between the
and a workstation: the server must have a service and the <acronym>KDC</acronym>. The secret is a cryptographic
<filename>keytab</filename>. This file contains the server's key, stored in a <quote>keytab</quote>. The keytab contains
host key, which allows it and the <acronym>KDC</acronym> to the server's host key, which allows it and the <acronym>KDC</acronym>
verify each others identity. It must be transmitted to the to verify each others' identity. It must be transmitted to the
server in a secure fashion, as the security of the server can server in a secure fashion, as the security of the server can
be broken if the key is made public. Typically, the be broken if the key is made public. Typically, the
<filename>keytab</filename> is transferred to the server using <filename>keytab</filename> is generated on an administrator's
<command>kadmin</command>. This is handy because the host trusted machine using <command>kadmin</command>, then securely
principal, the <acronym>KDC</acronym> end of the transferred to the server, e.g., with &man.scp.1;; it can also
<filename>krb5.keytab</filename>, is also created using be created directly on the server if that is consistent with
the desired security policy. It is very important that the
keytab is transmitted to the server in a secure fashion: if
the key is known by some other party, that party can impersonate
any user to the server! Using <command>kadmin</command> on the
server directly is convenient, because the entry for the host
principal in the <acronym>KDC</acronym> database is also created using
<command>kadmin</command>.</para> <command>kadmin</command>.</para>
<para>A ticket must first be obtained and this ticket must be <para>Of course, <command>kadmin</command> is a kerberized service;
allowed to use the <command>kadmin</command> interface in the a <application>Kerberos</application> ticket is needed to authenticate
to the network service, but to ensure that the user running
<command>kadmin</command> is actually present (and their session has
not been hijacked), <command>kadmin</command> will prompt for the
password to get a fresh ticket. The principal authenticating
to the kadmin service must be permitted to use the
<command>kadmin</command> interface, as specified in
<filename>kadmind.acl</filename>. See the section titled <filename>kadmind.acl</filename>. See the section titled
<quote>Remote administration</quote> in <command>info <quote>Remote administration</quote> in <command>info
heimdal</command> for details on designing access control heimdal</command> for details on designing access control
lists. Instead of enabling remote <command>kadmin</command> lists. Instead of enabling remote <command>kadmin</command>
access, the administrator can securely connect to the access, the administrator could securely connect to the
<acronym>KDC</acronym> via the local console or &man.ssh.1;, <acronym>KDC</acronym> via the local console or &man.ssh.1;,
and perform administration locally using and perform administration locally using
<command>kadmin -l</command>.</para> <command>kadmin -l</command>.</para>
<para>After installing <filename>/etc/krb5.conf</filename>, <para>After installing <filename>/etc/krb5.conf</filename>,
use <command>add --random-key</command> from the use <command>add --random-key</command> in <command>kadmin</command>.
<application>Kerberos</application> server. This adds the This adds the server's host principal to the database, but does not
server's host principal. Then, use <command>ext</command> to extract a copy of the host principal key to a keytab. To generate
extract the server's host principal to its own keytab:</para> the keytab, use <command>ext</command> to extract the server's host
principal key to its own keytab:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput> kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]: Max ticket life [unlimited]:
Max renewable life [unlimited]: Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []: Attributes []:
kadmin&gt;<userinput> ext <replaceable>host/myserver.example.org</replaceable></userinput> kadmin&gt;<userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput>
kadmin&gt;<userinput> exit</userinput></screen> kadmin&gt;<userinput> exit</userinput></screen>
<para>Note that <command>ext</command> stores the extracted key <para>Note that <command>ext_keytab</command> stores the extracted key
in <filename>/etc/krb5.keytab</filename> by default.</para> in <filename>/etc/krb5.keytab</filename> by default. This is
good when being run on the server being kerberized, but the
<para>If &man.kadmind.8; is not running on the <command>--keytab <replaceable>path/to/file</replaceable></command>
<acronym>KDC</acronym> and there is no access to argument should be used when the keytab is being extracted
&man.kadmin.8; remotely, add the server's host principal elsewhere:</para>
directly on the <acronym>KDC</acronym> and then extract it to
a temporary file to avoid overwriting the
<filename>/etc/krb5.keytab</filename> on the
<acronym>KDC</acronym>:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> ext --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput> kadmin&gt;<userinput> ext_keytab --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput>
kadmin&gt;<userinput> exit</userinput></screen> kadmin&gt;<userinput> exit</userinput></screen>
<para>The keytab can then be securely copied to the server <para>The keytab can then be securely copied to the server
using &man.scp.1; or a removable media. Be sure to specify a using &man.scp.1; or a removable media. Be sure to specify a
non-default keytab name to avoid overwriting the keytab on the non-default keytab name to avoid inserting unneeded keys into the
<acronym>KDC</acronym>.</para> system's keytab.</para>
<para>At this point, the server can communicate with the <para>At this point, the server can read encrypted messages from the
<acronym>KDC</acronym> using <acronym>KDC</acronym> using its shared key, stored in
<filename>krb5.conf</filename> and it can prove its own <filename>krb5.keytab</filename>. It is now
identity with <filename>krb5.keytab</filename>. It is now ready for the <application>Kerberos</application>-using services to
ready for the <application>Kerberos</application> services to be enabled. One of the most common such services is &man.sshd.8;,
be enabled. For this example, the &man.telnetd.8; service is which supports <application>Kerberos</application> via the
enabled in <filename>/etc/inetd.conf</filename> and <acronym>GSS-API</acronym>. In
&man.inetd.8; has been restarted with <command>service inetd <filename>/etc/ssh/sshd_config</filename>, add the line:</para>
restart</command>:</para>
<programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting> <programlisting>GSSAPIAuthentication yes</programlisting>
<para>The critical change is that the <option>-a</option> <para>After making this change, &man.sshd.8; must be restared for
authentication type is set to user. Refer to &man.telnetd.8; the new configuration to take effect: <command>service sshd
for more details.</para> restart</command>.</para>
</sect2> </sect2>
<sect2> <sect2>
@ -1401,36 +1428,34 @@ kadmin&gt;<userinput> exit</userinput></screen>
<secondary>configure clients</secondary> <secondary>configure clients</secondary>
</indexterm> </indexterm>
<para>To configure a client to use <para>As it was for the server, the client requires configuration in
<application>Kerberos</application>, securely copy <filename>/etc/krb5.conf</filename>. Copy the file in place
<filename>/etc/krb5.conf</filename> to the client computer (securely) or re-enter it as needed.</para>
from the <acronym>KDC</acronym>.</para>
<para>Test the client by using <command>kinit</command>, <para>Test the client by using <command>kinit</command>,
<command>klist</command>, and <command>kdestroy</command> from <command>klist</command>, and <command>kdestroy</command> from
the client to obtain, show, and then delete an existing ticket the client to obtain, show, and then delete a ticket
for the principal. <application>Kerberos</application> for an existing principal. <application>Kerberos</application>
applications should also be able to connect to applications should also be able to connect to
<application>Kerberos</application> enabled servers. If that <application>Kerberos</application> enabled servers. If that
does not work but obtaining a ticket does, the problem is does not work but obtaining a ticket does, the problem is
likely with the server and not with the client or the likely with the server and not with the client or the
<acronym>KDC</acronym>.</para> <acronym>KDC</acronym>. In the case of kerberized &man.ssh.1;,
<acronym>GSS-API</acronym> is disabled by default, so test using
<command>ssh -o GSSAPIAuthentication=yes
<replaceable>hostname</replaceable></command>.</para>
<para>When testing a Kerberized application, try using a packet <para>When testing a Kerberized application, try using a packet
sniffer such as <command>tcpdump</command> to confirm that the sniffer such as <command>tcpdump</command> to confirm that no
password is not sent in the clear.</para> sensitive information is sent in the clear.</para>
<para>Various <application>Kerberos</application> client <para>Various <application>Kerberos</application> client
applications are available. &os; installs applications are available. With the advent of a bridge so that
<command>telnetd</command> as the only applications using <acronym>SASL</acronym> for authentication can
<application>Kerberos</application> enabled service. The use <acronym>GSS-API</acronym> mechanisms as well, large classes
Heimdal package or port installs of client applications can use <application>Kerberos</application>
<application>Kerberos</application> enabled versions of for authentication, from Jabber clients to <acronym>IMAP</acronym>
<command>ftpd</command>, <command>rshd</command>, clients.</para>
<command>rcp</command>, <command>rlogind</command>, and a few
other less common programs. The <acronym>MIT</acronym> port
contains a full suite of <application>Kerberos</application>
client applications.</para>
<indexterm> <indexterm>
<primary><filename>.k5login</filename></primary> <primary><filename>.k5login</filename></primary>
@ -1489,20 +1514,8 @@ jdoe@example.org</screen>
<acronym>MIT</acronym> versions if <envar>PATH</envar> lists <acronym>MIT</acronym> versions if <envar>PATH</envar> lists
the system directories first.</para> the system directories first.</para>
<note> <para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;,
<para>With the &os; <acronym>MIT</acronym> the following edits should also be made to
<package>security/krb5</package> port, be sure to read
<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
installed by the port to understand why logins via
<command>telnetd</command> and <command>klogind</command>
behave somewhat oddly. 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>
<para>The following edits should also be made to
<filename>rc.conf</filename>:</para> <filename>rc.conf</filename>:</para>
<programlisting>kerberos5_server="/usr/local/sbin/krb5kdc" <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
@ -1523,9 +1536,8 @@ kadmind5_server_enable="YES"</programlisting>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>When using either Heimdal or <acronym>MIT</acronym> <para>When using either Heimdal or <acronym>MIT</acronym>
<application>Kerberos</application>, ensure that the <application>Kerberos</application> from ports, ensure that the
<envar>PATH</envar> lists the <envar>PATH</envar> lists the port's versions of the
<application>Kerberos</application> versions of the
client applications before the system versions.</para> client applications before the system versions.</para>
</listitem> </listitem>
@ -1541,7 +1553,7 @@ kadmind5_server_enable="YES"</programlisting>
class="username">host/</systemitem> principal must be class="username">host/</systemitem> principal must be
changed and the keytab updated. This also applies to changed and the keytab updated. This also applies to
special keytab entries like the <systemitem special keytab entries like the <systemitem
class="username">www/</systemitem> principal used for class="username">HTTP/</systemitem> principal used for
Apache's <package>www/mod_auth_kerb</package>.</para> Apache's <package>www/mod_auth_kerb</package>.</para>
</listitem> </listitem>
@ -1570,8 +1582,8 @@ kadmind5_server_enable="YES"</programlisting>
<para>With <acronym>MIT</acronym> <para>With <acronym>MIT</acronym>
<application>Kerberos</application>, to allow a <application>Kerberos</application>, to allow a
principal to have a ticket life longer than the default principal to have a ticket life longer than the default
ten hours, use <command>modify_principal</command> at the lifetime of ten hours, use <command>modify_principal</command>
&man.kadmin.8; prompt to change the at the &man.kadmin.8; prompt to change the
<literal>maxlife</literal> of both the principal in <literal>maxlife</literal> of both the principal in
question and the <systemitem question and the <systemitem
class="username">krbtgt</systemitem> principal. The class="username">krbtgt</systemitem> principal. The
@ -1606,17 +1618,6 @@ kadmind5_server_enable="YES"</programlisting>
the authenticity of each <acronym>TGT</acronym>.</para> the authenticity of each <acronym>TGT</acronym>.</para>
</listitem> </listitem>
<listitem>
<para>To use long ticket lifetimes when using
<application>OpenSSH</application> to connect to the
machine where the ticket is stored, make sure that
<application>Kerberos</application>
<option>TicketCleanup</option> is set to
<literal>no</literal> in
<filename>/etc/ssh/sshd_config</filename>. Otherwise,
tickets will be deleted at log out.</para>
</listitem>
<listitem> <listitem>
<para>Host principals can have a longer ticket lifetime. If <para>Host principals can have a longer ticket lifetime. If
the user principal has a lifetime of a week but the host the user principal has a lifetime of a week but the host
@ -1658,20 +1659,6 @@ kadmind5_server_enable="YES"</programlisting>
shells but the non-Kerberized <acronym>POP3</acronym> mail shells but the non-Kerberized <acronym>POP3</acronym> mail
server sends passwords in plain text.</para> server sends passwords in plain text.</para>
<para><application>Kerberos</application> is intended for
single-user workstations. In a multi-user environment,
<application>Kerberos</application> is less secure as it
stores the tickets in <filename>/tmp</filename>, which is
readable by all users. If a user is sharing a computer, it is
possible that the user's tickets can be stolen or copied by
another user.</para>
<para>This can be overcome with <command>kinit -c</command> or,
preferably, the <envar>KRB5CCNAME</envar> environment
variable. Storing the ticket in the user's home directory and
using file permissions are commonly used to mitigate this
problem.</para>
<para>The <acronym>KDC</acronym> is a single point of failure. <para>The <acronym>KDC</acronym> is a single point of failure.
By design, the <acronym>KDC</acronym> must be as secure as its By design, the <acronym>KDC</acronym> must be as secure as its
master password database. The <acronym>KDC</acronym> should master password database. The <acronym>KDC</acronym> should
@ -1705,45 +1692,6 @@ kadmind5_server_enable="YES"</programlisting>
alleviate this.</para> alleviate this.</para>
</sect2> </sect2>
<sect2>
<title>Access Issues with Kerberos and
<command>ssh</command></title>
<indexterm><primary>&man.ssh.1;</primary></indexterm>
<para>Kerberos is an excellent authentication protocol, but
there are bugs in the Kerberized versions of
<command>telnet</command> and <command>rlogin</command> that
make them unsuitable for dealing with binary streams. By
default, Kerberos does not encrypt a session unless
<option>-x</option> is used, whereas <command>ssh</command>
encrypts everything.</para>
<para>While <command>ssh</command> works well, it forwards
encryption keys by default. This introduces a security risk
to a user who uses <command>ssh</command> to access an
insecure machine from a secure workstation. The keys
themselves are not exposed, but <command>ssh</command>
installs a forwarding port for the duration of the login. If
an attacker has broken <systemitem
class="username">root</systemitem> on the insecure machine,
he can utilize that port to gain access to any other machine
that those keys unlock.</para>
<para>It is recommended that <command>ssh</command> is used in
combination with Kerberos whenever possible for staff logins
as it can be compiled with Kerberos support. This reduces
reliance on potentially exposed <acronym>SSH</acronym> keys
while protecting passwords via Kerberos. Keys should only be
used for automated tasks from secure machines as this is
something that Kerberos is unsuited to. It is recommended to
either turn off key-forwarding in the
<acronym>SSH</acronym> configuration, or to make use of
<literal>from=IP/DOMAIN</literal> in
<filename>authorized_keys</filename> to make the key only
usable to entities logging in from specific machines.</para>
</sect2>
<sect2> <sect2>
<title>Resources and Further Information</title> <title>Resources and Further Information</title>
@ -1769,8 +1717,8 @@ kadmind5_server_enable="YES"</programlisting>
<listitem> <listitem>
<para><link <para><link
xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC xlink:href="http://www.ietf.org/rfc/rfc4120.txt?number=4120">RFC
1510, The <application>Kerberos</application> Network 4120, The <application>Kerberos</application> Network
Authentication Service (V5)</link></para> Authentication Service (V5)</link></para>
</listitem> </listitem>