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
authentication protocol which was originally created by the
Massachusetts Institute of Technology
(<acronym>MIT</acronym>) as a solution to network security
problems. The <application>Kerberos</application> protocol uses
(<acronym>MIT</acronym>) as a way to securely provide authentication
across a potentially hostile network.
The <application>Kerberos</application> protocol uses
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
identity-verifying proxy system and as a trusted third-party
authentication system. After a user authenticates with
@ -1106,29 +1107,36 @@ sendmail : PARANOID : deny</programlisting>
encrypted to assure privacy and data integrity.</para>
<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
recommended that <application>Kerberos</application> be used
with other security methods which provide authorization and
audit services.</para>
<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
range of operating systems. <acronym>MIT</acronym> continues to
develop their <application>Kerberos</application> package. It
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>MIT</acronym> <application>Kerberos</application> is
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
avoid export regulations. The Heimdal
<application>Kerberos</application> distribution is available as
the <package>security/heimdal</package> package or port, and a
minimal installation is included in the base &os;
install.</para>
<application>Kerberos</application> distribution is included in
the base &os; installation, and another distribution with more
configurable options is available as <package>security/heimdal</package>
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
<application>Kerberos</application> using the Heimdal
@ -1169,12 +1177,14 @@ sendmail : PARANOID : deny</programlisting>
<para>The Key Distribution Center (<acronym>KDC</acronym>) is
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>
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
<application>Kerberos</application> realm, and thus has
heightened security concerns.</para>
<application>Kerberos</application> realm, it has heightened security
concerns. Direct access to the KDC should be limited.</para>
<para>While running a <acronym>KDC</acronym> requires few
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
fully-qualified hostname <systemitem
class="fqdomainname">kerberos.example.org</systemitem>. Add
a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym>
zone file if the <acronym>KDC</acronym> has a different
hostname than that specified in
<filename>/etc/krb5.conf</filename>.</para>
class="fqdomainname">kerberos.example.org</systemitem>. The
hostname of the KDC must be resolvable in the
<acronym>DNS</acronym>.</para>
<para>For large networks with a properly configured
<acronym>DNS</acronym> server, the above example could be
trimmed to:</para>
<para><application>Kerberos</application> can also use the
<acronym>DNS</acronym> to locate KDCs, instead of a
<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]
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
file:</para>
@ -1227,8 +1240,8 @@ _kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programl
<note>
<para>In order for clients to be able to find the
<application>Kerberos</application> services, the
<acronym>KDC</acronym> <emphasis>must</emphasis> have either
<application>Kerberos</application> services, they
<emphasis>must</emphasis> have either
a fully configured <filename>/etc/krb5.conf</filename> or a
minimally configured <filename>/etc/krb5.conf</filename>
<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
hosts) encrypted with a master password. It is not required
to remember this password as it will be stored in
<filename>/var/heimdal/m-key</filename>. To create the master
key, run <command>kstash</command> and enter a
<filename>/var/heimdal/m-key</filename>; it would be reasonable to
use a 45-character random password for this purpose. To create the
master key, run <command>kstash</command> and enter a
password:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
Verifying password - Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
<para>Once the master key has been created, initialize the
database using <command>kadmin -l</command>. This option
instructs <command>kadmin</command> to modify the local
database files directly rather than going through the
&man.kadmind.8; network service. This handles the
chicken-and-egg problem of trying to connect to the database
<para>Once the master key has been created, the database should be
initialized. The <application>Kerberos</application> administrative
tool &man.kadmin.8; can be used on the KDC in a mode that
operates directly on the database, without using the &man.kadmind.8;
network service, as <command>kadmin -l</command>.
This resolves the chicken-and-egg problem of trying to connect to
the database
before it is created. At the <command>kadmin</command>
prompt, use <command>init</command> to create the realm's
initial database:</para>
@ -1280,21 +1295,22 @@ Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></u
<command>service kadmind start</command>. While there will
not be any kerberized daemons running at this point, it is
possible to confirm that the <acronym>KDC</acronym> is
functioning by obtaining and listing a ticket for the
principal that was just created from the command-line of the
<acronym>KDC</acronym>:</para>
functioning by obtaining a ticket for the
principal that was just created:</para>
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password:
&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:/tmp/krb5cc_500
</screen>
<para>Confirm that a ticket was successfully obtained using
<command>klist</command>:</para>
<screen>&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:/tmp/krb5cc_1001
Principal: tillman@EXAMPLE.ORG
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
Issued Expires Principal
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>
<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>
</indexterm>
<para>To configure a server to use
<application>Kerberos</application> authentication, copy
<filename>/etc/krb5.conf</filename> from the
<acronym>KDC</acronym> to the server in a secure fashion, such
as &man.scp.1;, or physically via removable media.</para>
<para>The first step in configuring a server to use
<application>Kerberos</application> authentication is to
ensure that it has the correct configuration in
<filename>/etc/krb5.conf</filename>. The version from the
<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
server. 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>. This file contains the server's
host key, which allows it and the <acronym>KDC</acronym> to
verify each others identity. It must be transmitted to the
server. This is the main part of <quote>Kerberizing</quote> a service
&mdash; it corresponds to generating a secret shared between the
service and the <acronym>KDC</acronym>. The secret is a cryptographic
key, stored in a <quote>keytab</quote>. The keytab contains
the server's 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. Typically, the
<filename>keytab</filename> is transferred to the server using
<command>kadmin</command>. This is handy because the host
principal, the <acronym>KDC</acronym> end of the
<filename>krb5.keytab</filename>, is also created using
<filename>keytab</filename> is generated on an administrator's
trusted machine using <command>kadmin</command>, then securely
transferred to the server, e.g., with &man.scp.1;; it can also
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>
<para>A ticket must first be obtained and this ticket must be
allowed to use the <command>kadmin</command> interface in the
<para>Of course, <command>kadmin</command> is a kerberized service;
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
<quote>Remote administration</quote> in <command>info
heimdal</command> for details on designing access control
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;,
and perform administration locally using
<command>kadmin -l</command>.</para>
<para>After installing <filename>/etc/krb5.conf</filename>,
use <command>add --random-key</command> from the
<application>Kerberos</application> server. This adds the
server's host principal. Then, use <command>ext</command> to
extract the server's host principal to its own keytab:</para>
use <command>add --random-key</command> in <command>kadmin</command>.
This adds the server's host principal to the database, but does not
extract a copy of the host principal key to a keytab. To generate
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>
kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
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>
<para>Note that <command>ext</command> stores the extracted key
in <filename>/etc/krb5.keytab</filename> by default.</para>
<para>If &man.kadmind.8; is not running on the
<acronym>KDC</acronym> and there is no access to
&man.kadmin.8; remotely, add the server's host principal
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>
<para>Note that <command>ext_keytab</command> stores the extracted key
in <filename>/etc/krb5.keytab</filename> by default. This is
good when being run on the server being kerberized, but the
<command>--keytab <replaceable>path/to/file</replaceable></command>
argument should be used when the keytab is being extracted
elsewhere:</para>
<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>
<para>The keytab can then be securely copied to the server
using &man.scp.1; or a removable media. Be sure to specify a
non-default keytab name to avoid overwriting the keytab on the
<acronym>KDC</acronym>.</para>
non-default keytab name to avoid inserting unneeded keys into the
system's keytab.</para>
<para>At this point, the server can communicate with the
<acronym>KDC</acronym> using
<filename>krb5.conf</filename> and it can prove its own
identity with <filename>krb5.keytab</filename>. It is now
ready for the <application>Kerberos</application> services to
be enabled. For this example, the &man.telnetd.8; service is
enabled in <filename>/etc/inetd.conf</filename> and
&man.inetd.8; has been restarted with <command>service inetd
restart</command>:</para>
<para>At this point, the server can read encrypted messages from the
<acronym>KDC</acronym> using its shared key, stored in
<filename>krb5.keytab</filename>. It is now
ready for the <application>Kerberos</application>-using services to
be enabled. One of the most common such services is &man.sshd.8;,
which supports <application>Kerberos</application> via the
<acronym>GSS-API</acronym>. In
<filename>/etc/ssh/sshd_config</filename>, add the line:</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>
authentication type is set to user. Refer to &man.telnetd.8;
for more details.</para>
<para>After making this change, &man.sshd.8; must be restared for
the new configuration to take effect: <command>service sshd
restart</command>.</para>
</sect2>
<sect2>
@ -1401,36 +1428,34 @@ kadmin&gt;<userinput> exit</userinput></screen>
<secondary>configure clients</secondary>
</indexterm>
<para>To configure a client to use
<application>Kerberos</application>, securely copy
<filename>/etc/krb5.conf</filename> to the client computer
from the <acronym>KDC</acronym>.</para>
<para>As it was for the server, the client requires configuration in
<filename>/etc/krb5.conf</filename>. Copy the file in place
(securely) or re-enter it as needed.</para>
<para>Test the client by using <command>kinit</command>,
<command>klist</command>, and <command>kdestroy</command> from
the client to obtain, show, and then delete an existing ticket
for the principal. <application>Kerberos</application>
the client to obtain, show, and then delete a ticket
for an existing principal. <application>Kerberos</application>
applications should also be able to connect to
<application>Kerberos</application> enabled servers. If that
does not work but obtaining a ticket does, the problem is
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
sniffer such as <command>tcpdump</command> to confirm that the
password is not sent in the clear.</para>
sniffer such as <command>tcpdump</command> to confirm that no
sensitive information is sent in the clear.</para>
<para>Various <application>Kerberos</application> client
applications are available. &os; installs
<command>telnetd</command> as the only
<application>Kerberos</application> enabled service. The
Heimdal package or port installs
<application>Kerberos</application> enabled versions of
<command>ftpd</command>, <command>rshd</command>,
<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>
applications are available. With the advent of a bridge so that
applications using <acronym>SASL</acronym> for authentication can
use <acronym>GSS-API</acronym> mechanisms as well, large classes
of client applications can use <application>Kerberos</application>
for authentication, from Jabber clients to <acronym>IMAP</acronym>
clients.</para>
<indexterm>
<primary><filename>.k5login</filename></primary>
@ -1489,20 +1514,8 @@ jdoe@example.org</screen>
<acronym>MIT</acronym> versions if <envar>PATH</envar> lists
the system directories first.</para>
<note>
<para>With the &os; <acronym>MIT</acronym>
<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
<para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;,
the following edits should also be made to
<filename>rc.conf</filename>:</para>
<programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
@ -1523,9 +1536,8 @@ kadmind5_server_enable="YES"</programlisting>
<itemizedlist>
<listitem>
<para>When using either Heimdal or <acronym>MIT</acronym>
<application>Kerberos</application>, ensure that the
<envar>PATH</envar> lists the
<application>Kerberos</application> versions of the
<application>Kerberos</application> from ports, ensure that the
<envar>PATH</envar> lists the port's versions of the
client applications before the system versions.</para>
</listitem>
@ -1541,7 +1553,7 @@ kadmind5_server_enable="YES"</programlisting>
class="username">host/</systemitem> principal must be
changed and the keytab updated. This also applies to
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>
</listitem>
@ -1570,8 +1582,8 @@ kadmind5_server_enable="YES"</programlisting>
<para>With <acronym>MIT</acronym>
<application>Kerberos</application>, to allow a
principal to have a ticket life longer than the default
ten hours, use <command>modify_principal</command> at the
&man.kadmin.8; prompt to change the
lifetime of ten hours, use <command>modify_principal</command>
at the &man.kadmin.8; prompt to change the
<literal>maxlife</literal> of both the principal in
question and the <systemitem
class="username">krbtgt</systemitem> principal. The
@ -1606,17 +1618,6 @@ kadmind5_server_enable="YES"</programlisting>
the authenticity of each <acronym>TGT</acronym>.</para>
</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>
<para>Host principals can have a longer ticket lifetime. If
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
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.
By design, the <acronym>KDC</acronym> must be as secure as its
master password database. The <acronym>KDC</acronym> should
@ -1705,45 +1692,6 @@ kadmind5_server_enable="YES"</programlisting>
alleviate this.</para>
</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>
<title>Resources and Further Information</title>
@ -1769,8 +1717,8 @@ kadmind5_server_enable="YES"</programlisting>
<listitem>
<para><link
xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC
1510, The <application>Kerberos</application> Network
xlink:href="http://www.ietf.org/rfc/rfc4120.txt?number=4120">RFC
4120, The <application>Kerberos</application> Network
Authentication Service (V5)</link></para>
</listitem>