Finish editorial review of Kerberos chapter.

Sponsored by:	iXsystems

en_US.ISO8859-1/books/handbook/security/chapter.xml

@@ -1366,23 +1366,24 @@ kadmin&gt;<userinput> exit</userinput></screen>
     </sect2>
 
     <sect2>
-      <title><application>Kerberos</application> Enabling a Client
+      <title>Configuring a Client to use
-	with Heimdal</title>
+	<application>Kerberos</application></title>
 
       <indexterm>
 	<primary>Kerberos5</primary>
 	<secondary>configure clients</secondary>
       </indexterm>
 
-      <para>Setting up a client computer is easy as only
+      <para>To configure a client to use
-	<filename>/etc/krb5.conf</filename> is needed.  Securely copy
+	<application>Kerberos</application>, securely copy
-	this file over to the client computer from the
+	<filename>/etc/krb5.conf</filename>
+	to the client computer from the
 	<acronym>KDC</acronym>.</para>
 
-      <para>Test the client by attempting to use &man.kinit.1;,
+      <para>Test the client by using <command>kinit</command>,
-	&man.klist.1;, and &man.kdestroy.1; from the client to obtain,
+	<command>klist</command>, and <command>kdestroy</command> from the client to obtain,
-	show, and then delete a ticket for the principal created
+	show, and then delete an existing ticket for the principal.
-	above.  <application>Kerberos</application> applications
+	<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
@@ -1390,26 +1391,21 @@ kadmin&gt;<userinput> exit</userinput></screen>
 	<acronym>KDC</acronym>.</para>
 
       <para>When testing a Kerberized application, try using a packet
-	sniffer such as &man.tcpdump.1; to confirm that the password
+	sniffer such as <command>tcpdump</command> to confirm that the password
 	is not sent in the clear.</para>
 
-      <para>Various non-core <application>Kerberos</application>
+      <para>Various <application>Kerberos</application>
-	client applications are available.  The <quote>minimal</quote>
+	client applications are available.
-	installation in &os; installs &man.telnetd.8; as the only
+	&os; installs <command>telnetd</command> as the only
-	<application>Kerberos</application> enabled service.</para>
+	<application>Kerberos</application> enabled service.  The
-
+	Heimdal package or port installs
-      <para>The Heimdal port installs
 	<application>Kerberos</application> enabled versions of
-	&man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and
+	<command>ftpd</command>, <command>rshd</command>,
+	<command>rcp</command>, <command>rlogind</command>, and
 	a few other less common programs.  The <acronym>MIT</acronym>
-	port also contains a full suite of
+	port contains a full suite of
 	<application>Kerberos</application> client
 	applications.</para>
-    </sect2>
-
-    <sect2>
-      <title>User Configuration Files: <filename>.k5login</filename>
-	and <filename>.k5users</filename></title>
 
       <indexterm>
 	<primary><filename>.k5login</filename></primary>
@@ -1433,7 +1429,7 @@ kadmin&gt;<userinput> exit</userinput></screen>
       <para>The <filename>.k5login</filename> and
 	<filename>.k5users</filename> files, placed in a user's home
 	directory, can be used to solve this problem.  For example, if
-	<filename>.k5login</filename> with the following contents is
+	the following <filename>.k5login</filename> is
 	placed in the home directory of <systemitem
 	  class="username">webdevelopers</systemitem>, both principals
 	listed will have access to that account without requiring a
@@ -1446,16 +1442,64 @@ jdoe@example.org</screen>
 	<filename>.k5users</filename>.</para>
     </sect2>
 
+    <sect2>
+      <title><acronym>MIT</acronym> Differences</title>
+
+      <para>The major difference between the <acronym>MIT</acronym> and
+	Heimdal implementations is that <command>kadmin</command> has a different, but
+	equivalent, set of commands and uses a different protocol.
+	If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
+	Heimdal version of <command>kadmin</command> cannot be used to administer
+	the <acronym>KDC</acronym> remotely, and vice versa.</para>
+
+      <para>Client applications may also use slightly different
+	command line options to accomplish the same tasks.
+	Following the instructions at
+	<application>Kerberos</application> <link
+	  xlink:href="http://web.mit.edu/Kerberos/www/">http://web.mit.edu/Kerberos/www/</link>
+	is recommended.  Be careful of path issues: the
+	<acronym>MIT</acronym> port installs into
+	<filename>/usr/local/</filename> by default, and the
+	&os; system applications run instead of the
+	<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
+	<filename>rc.conf</filename>:</para>
+
+      <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
+kadmind5_server="/usr/local/sbin/kadmind"
+kerberos5_server_flags=""
+kerberos5_server_enable="YES"
+kadmind5_server_enable="YES"</programlisting>
+    </sect2>
+
     <sect2>
       <title><application>Kerberos</application> Tips, Tricks, and
 	Troubleshooting</title>
 
+      <para>When configuring and troubleshooting
+	<application>Kerberos</application>, keep the following points
+	in mind:</para>
+ 
       <itemizedlist>
 	<listitem>
-	  <para>When using either the Heimdal or
+	  <para>When using either Heimdal or
 	    <acronym>MIT</acronym>
-	    <application>Kerberos</application><indexterm><primary>Kerberos5</primary><secondary>troubleshooting</secondary></indexterm>
+	    <application>Kerberos</application>, ensure that the <envar>PATH</envar> lists the
-	    ports, ensure that the <envar>PATH</envar> lists the
 	    <application>Kerberos</application> versions of the
 	    client applications before the system versions.</para>
 	</listitem>
@@ -1467,12 +1511,6 @@ jdoe@example.org</screen>
 	    clocks using <acronym>NTP</acronym>.</para>
 	</listitem>
 
-	<listitem>
-	  <para><acronym>MIT</acronym> and Heimdal interoperate
-	    except for &man.kadmin.8;, which is not
-	    standardized.</para>
-	</listitem>
-
 	<listitem>
 	  <para>If the hostname is changed, the <systemitem
 	      class="username">host/</systemitem> principal must be
@@ -1485,7 +1523,7 @@ jdoe@example.org</screen>
 	<listitem>
 	  <para>All hosts in the realm must be both forward and
 	    reverse resolvable in <acronym>DNS</acronym> or, at a
-	    minimum, in <filename>/etc/hosts</filename>.  CNAMEs
+	    minimum, exist in <filename>/etc/hosts</filename>.  CNAMEs
 	    will work, but the A and PTR records must be correct and
 	    in place.  The error message for unresolvable hosts is not
 	    intuitive: <errorname>Kerberos5 refuses authentication
@@ -1496,31 +1534,30 @@ jdoe@example.org</screen>
 	<listitem>
 	  <para>Some operating systems that act as clients to the
 	    <acronym>KDC</acronym> do not set the permissions for
-	    &man.ksu.1; to be setuid <systemitem
+	    <command>ksu</command> to be setuid <systemitem
 	      class="username">root</systemitem>.  This means that
-	    &man.ksu.1; does not work.  This is not a
+	    <command>ksu</command> does not work.  This is a permissions problem, not a
 	    <acronym>KDC</acronym> error.</para>
 	</listitem>
 
 	<listitem>
 	  <para>With <acronym>MIT</acronym>
-	    <application>Kerberos</application>, in order to allow a
+	    <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 maxlife of both 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.  Then
+	      class="username">krbtgt</systemitem> principal.  The
-	    the principal can use <command>kinit -l</command> to
+	    principal can then use <command>kinit -l</command> to
 	    request a ticket with a longer lifetime.</para>
 	</listitem>
 
 	<listitem>
-	  <note>
 	    <para>When running a packet sniffer on the
 	      <acronym>KDC</acronym> to aid in troubleshooting while
-	      running &man.kinit.1; from a workstation, the Ticket
+	      running <command>kinit</command> from a workstation, the Ticket
 	      Granting Ticket (<acronym>TGT</acronym>) is sent
-	      immediately upon running &man.kinit.1;, even before the
+	      immediately, even before the
 	      password is typed.  This is because the
 	      <application>Kerberos</application> server freely
 	      transmits a <acronym>TGT</acronym> to any unauthorized
@@ -1528,7 +1565,7 @@ jdoe@example.org</screen>
 	      encrypted in a key derived from the user's password.
 	      When a user types their password, it is not sent to the
 	      <acronym>KDC</acronym>, it is instead used to decrypt
-	      the <acronym>TGT</acronym> that &man.kinit.1; already
+	      the <acronym>TGT</acronym> that <command>kinit</command> already
 	      obtained.  If the decryption process results in a valid
 	      ticket with a valid time stamp, the user has valid
 	      <application>Kerberos</application> credentials.
@@ -1541,17 +1578,16 @@ jdoe@example.org</screen>
 	      This second layer of encryption allows the
 	      <application>Kerberos</application> server to verify
 	      the authenticity of each <acronym>TGT</acronym>.</para>
-	  </note>
 	</listitem>
 
 	<listitem>
-	  <para>To use long ticket lifetimes, such as a week, when
+	  <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>sshd_config</filename> or else tickets will be
+	    <filename>/etc/ssh/sshd_config</filename>.  Otherwise, tickets will be
 	    deleted at log out.</para>
 	</listitem>
 
@@ -1578,106 +1614,45 @@ jdoe@example.org</screen>
     </sect2>
 
     <sect2>
-      <title>Differences with the <acronym>MIT</acronym>
+      <title>Mitigating <application>Kerberos</application> Limitations</title>
-	Port</title>
-
-      <para>The major difference between <acronym>MIT</acronym> and
-	Heimdal relates to &man.kadmin.8; which has a different, but
-	equivalent, set of commands and uses a different protocol.
-	If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
-	Heimdal version of &man.kadmin.8; cannot be used to administer
-	the <acronym>KDC</acronym> remotely, and vice versa.</para>
-
-      <para>The client applications may also use slightly different
-	command line options to accomplish the same tasks.
-	Following the instructions on the <acronym>MIT</acronym>
-	<application>Kerberos</application> <link
-	  xlink:href="http://web.mit.edu/Kerberos/www/">web
-	  site</link> 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 run instead of
-	<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
-	  &man.telnetd.8; 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>
-
-      <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
-kadmind5_server="/usr/local/sbin/kadmind"
-kerberos5_server_flags=""
-kerberos5_server_enable="YES"
-kadmind5_server_enable="YES"</programlisting>
-
-      <para>This is done because the applications for
-	<acronym>MIT</acronym> Kerberos installs binaries in the
-	<filename>/usr/local</filename> hierarchy.</para>
-    </sect2>
-
-    <sect2>
-      <title>Mitigating Limitations Found in
-	<application>Kerberos</application></title>
 
       <indexterm>
 	<primary>Kerberos5</primary>
 	<secondary>limitations and shortcomings</secondary>
       </indexterm>
 
-      <sect3>
+	<para>Since <application>Kerberos</application> is an all or
-	<title><application>Kerberos</application> is an All or
+	  nothing approach, every service enabled on the network must either be modified
-	  Nothing Approach</title>
+	  to work with <application>Kerberos</application> or be
-
+	  otherwise secured against network attacks.  This is to prevent
-	<para>Every service enabled on the network must be modified
+	  user credentials from being stolen and re-used.  An example is when
-	  to work with <application>Kerberos</application>, or be
+	  <application>Kerberos</application> is
-	  otherwise secured against network attacks, or else the
+	  enabled on all remote shells but the non-Kerberized
-	  user's credentials could be stolen and re-used.  An example
+	  <acronym>POP3</acronym> mail server sends passwords in
-	  of this would be <application>Kerberos</application>
-	  enabling all remote shells but not converting the
-	  <acronym>POP3</acronym> mail server which sends passwords in
 	  plain text.</para>
-      </sect3>
 
-      <sect3>
+	<para><application>Kerberos</application> is intended for
-	<title><application>Kerberos</application> is Intended for
+	  single-user workstations.  In a multi-user environment,
-	  Single-User Workstations</title>
+	  <application>Kerberos</application> is less secure as it
-
+	  stores the tickets in <filename>/tmp</filename>,
-	<para>In a multi-user environment,
-	  <application>Kerberos</application> is less secure.  This is
-	  because it stores the tickets in <filename>/tmp</filename>,
 	  which is readable by all users.  If a user is sharing a
-	  computer with other users, it is possible that the user's
+	  computer, it is possible that the user's
 	  tickets can be stolen or copied by another user.</para>
 
-	<para>This can be overcome with the <literal>-c</literal>
+	<para>This can be overcome with <command>kinit -c</command>
-	  command-line option or, preferably, the
+	  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>
-      </sect3>
 
-      <sect3>
+	<para>The <acronym>KDC</acronym> is a single point of failure.  By design, the
-	<title>The KDC is a Single Point of Failure</title>
+	  <acronym>KDC</acronym> must be as secure
-
-	<para>By design, the <acronym>KDC</acronym> must be as secure
 	  as its master password database.  The <acronym>KDC</acronym>
 	  should have absolutely no other services running on it and
 	  should be physically secure.  The danger is high because
 	  <application>Kerberos</application> stores all passwords
-	  encrypted with the same <quote>master</quote> key which is
+	  encrypted with the same master key which is
 	  stored as a file on the <acronym>KDC</acronym>.</para>
 
 	<para>A compromised master key is not quite as bad as one
@@ -1687,56 +1662,49 @@ kadmind5_server_enable="YES"</programlisting>
 	  <acronym>KDC</acronym> is secure, an attacker cannot do much
 	  with the master key.</para>
 
-	<para>Additionally, if the <acronym>KDC</acronym> is
+	<para>If the <acronym>KDC</acronym> is
 	  unavailable, network services are unusable as authentication
 	  cannot be performed.  This can be alleviated with a single
 	  master <acronym>KDC</acronym> and one or more slaves, and
 	  with careful implementation of secondary or fall-back
 	  authentication using <acronym>PAM</acronym>.</para>
-      </sect3>
-
-      <sect3>
-	<title><application>Kerberos</application>
-	  Shortcomings</title>
 
 	<para><application>Kerberos</application> allows users, hosts
 	  and services to authenticate between themselves.  It does
 	  not have a mechanism to authenticate the
-	  <acronym>KDC</acronym> to the users, hosts or services.
+	  <acronym>KDC</acronym> to the users, hosts, or services.
-	  This means that a trojanned &man.kinit.1; could record all
+	  This means that a trojanned <command>kinit</command> could record all
 	  user names and passwords.  File system integrity checking
 	  tools like <package>security/tripwire</package> can
 	  alleviate this.</para>
-      </sect3>
     </sect2>
 
     <sect2>
-      <title>Access Issues with Kerberos and &man.ssh.1;</title>
+      <title>Access Issues with Kerberos and <command>ssh</command></title>
 
       <indexterm><primary>&man.ssh.1;</primary></indexterm>
 
-      <para>There are a few issues with both Kerberos and &man.ssh.1;
+      <para>Kerberos is an
-	that need to be addressed if they are used.  Kerberos is an
 	excellent authentication protocol, but there are bugs in the
-	kerberized versions of &man.telnet.1; and &man.rlogin.1; that
+	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  &man.ssh.1; encrypts
+	<option>-x</option> is used, whereas  <command>ssh</command> encrypts
 	everything.</para>
 
-      <para>While &man.ssh.1; works well, it forwards encryption keys
+      <para>While <command>ssh</command> works well, it forwards encryption keys
 	by default.  This introduces a security risk to a user who
-	uses &man.ssh.1; to access an insecure machine from a secure
+	uses <command>ssh</command> to access an insecure machine from a secure
 	workstation.  The keys themselves are not exposed, but
-	&man.ssh.1; installs a forwarding port for the duration of the
+	<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 &man.ssh.1; is used in combination
+      <para>It is recommended that <command>ssh</command> is used in combination
-	with Kerberos whenever possible for staff logins and
+	with Kerberos whenever possible for staff logins as it
-	&man.ssh.1; can be compiled with Kerberos support.  This
+	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