svn commit: r44442 - head/en_US.ISO8859-1/books/handbook/security

Dru Lavigne dru at FreeBSD.org
Fri Apr 4 14:30:08 UTC 2014


Author: dru
Date: Fri Apr  4 14:30:07 2014
New Revision: 44442
URL: http://svnweb.freebsd.org/changeset/doc/44442

Log:
  Editorial review of first 1/2 of Kerberos chapter.
  
  Sponsored by:	iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/security/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Fri Apr  4 13:26:26 2014	(r44441)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Fri Apr  4 14:30:07 2014	(r44442)
@@ -303,7 +303,7 @@
 	time, all network logins should avoid the use of passwords in
 	exchange for this two factor authentication method.  For
 	more information see the <xref linkend="openssh"/> section of
-	the handbook.  Kerberose users may need to make additional
+	the handbook.  Kerberos users may need to make additional
 	changes to implement <application>OpenSSH</application> in
 	their network.</para>
 
@@ -1050,7 +1050,7 @@ sendmail : PARANOID : deny</programlisti
 
   <sect1 xml:id="kerberos5">
     <info>
-      <title><application>Kerberos5</application></title>
+      <title><application>Kerberos</application></title>
 
       <authorgroup>
 	<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed
@@ -1062,11 +1062,15 @@ sendmail : PARANOID : deny</programlisti
       </authorgroup>
     </info>
 
-    <para><application>Kerberos</application> is a network add-on
-      system/protocol that allows users to authenticate themselves
-      through the services of a secure server.
+    <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
+      strong cryptography so that both a client and server can prove
+      their identity over an insecure network.
       <application>Kerberos</application> can be described as an
-      identity-verifying proxy system.  It can also be described as a
+      identity-verifying proxy system and as a
       trusted third-party authentication system.  After a user
       authenticates with <application>Kerberos</application>, their
       communications can be encrypted to assure privacy and data
@@ -1074,24 +1078,42 @@ sendmail : PARANOID : deny</programlisti
 
     <para>The only function of <application>Kerberos</application> is
       to provide the secure authentication of users on the network.
-      It does not provide authorization functions (what users are
-      allowed to do) or auditing functions (what those users did).  It
+      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> 1510.  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
+	<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 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>
+
     <para>This section provides a guide on how to set up
-      <application>Kerberos</application> as distributed for &os;.
-      Refer to the relevant manual pages for more complete
-      descriptions.</para>
+      <application>Kerberos</application> using the Heimdal
+	distribution included in &os;.</para>
 
     <para>For purposes of demonstrating a
-      <application>Kerberos</application> installation, the various
+      <application>Kerberos</application> installation, the
       name spaces will be as follows:</para>
 
     <itemizedlist>
       <listitem>
-	<para>The <acronym>DNS</acronym> domain (<quote>zone</quote>)
+	<para>The <acronym>DNS</acronym> domain (zone)
 	  will be <systemitem
 	    class="fqdomainname">example.org</systemitem>.</para>
       </listitem>
@@ -1104,58 +1126,13 @@ sendmail : PARANOID : deny</programlisti
 
     <note>
       <para>Use real domain names when setting up
-	<application>Kerberos</application> even if it will run
+	<application>Kerberos</application>, even if it will run
 	internally.  This avoids <acronym>DNS</acronym> problems
 	and assures inter-operation with other
 	<application>Kerberos</application> realms.</para>
     </note>
 
     <sect2>
-      <title>History</title>
-
-      <indexterm>
-	<primary>Kerberos5</primary>
-	<secondary>history</secondary>
-      </indexterm>
-
-      <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> is both the name of a
-	network authentication protocol and an adjective to describe
-	programs that implement it, such as
-	<application>Kerberos</application> telnet.  The current
-	version of the protocol is version 5, described in
-	<acronym>RFC</acronym> 1510.</para>
-
-      <para>Several free implementations of this protocol are
-	available, covering a wide range of operating systems.  The
-	Massachusetts Institute of Technology
-	(<acronym>MIT</acronym>), where
-	<application>Kerberos</application> was originally developed,
-	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
-	<acronym>US</acronym> export regulations.  The
-	<acronym>MIT</acronym> <application>Kerberos</application> is
-	available as the <package>security/krb5</package> package or
-	port.  Heimdal <application>Kerberos</application> is another
-	version 5 implementation, and was explicitly developed outside
-	of the <acronym>US</acronym> to avoid export regulations.  The
-	Heimdal <application>Kerberos</application> distribution is
-	available as a the <package>security/heimdal</package> package
-	or port, and a minimal installation is included in the base
-	&os; install.</para>
-
-      <para>These instructions assume the use of the Heimdal
-	distribution included in &os;.</para>
-    </sect2>
-
-    <sect2>
       <title>Setting up a Heimdal <acronym>KDC</acronym></title>
 
       <indexterm>
@@ -1168,19 +1145,17 @@ sendmail : PARANOID : deny</programlisti
 	<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
+	trusted by all other computers in the
 	<application>Kerberos</application> realm, and thus has
 	heightened security concerns.</para>
 
-      <para>While running the <application>Kerberos</application>
-	server requires very few computing resources, a dedicated
+      <para>While running a <acronym>KDC</acronym>
+	requires 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
-	<filename>/etc/rc.conf</filename> contains the correct
-	settings to act as a <acronym>KDC</acronym>.  As required,
-	adjust paths to reflect the system:</para>
+      <para>To begin setting up a <acronym>KDC</acronym>, add these lines to
+	<filename>/etc/rc.conf</filename>:</para>
 
       <programlisting>kerberos5_server_enable="YES"
 kadmind5_server_enable="YES"</programlisting>
@@ -1189,132 +1164,131 @@ kadmind5_server_enable="YES"</programlis
 	follows:</para>
 
       <programlisting>[libdefaults]
-    default_realm = EXAMPLE.ORG
+    default_realm = <replaceable>EXAMPLE.ORG</replaceable>
 [realms]
-    EXAMPLE.ORG = {
-        kdc = kerberos.example.org
-        admin_server = kerberos.example.org
+    <replaceable>EXAMPLE.ORG</replaceable> = {
+	kdc = <replaceable>kerberos.example.org</replaceable>
+	admin_server = <replaceable>kerberos.example.org</replaceable>
     }
 [domain_realm]
-    .example.org = EXAMPLE.ORG</programlisting>
+    <replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
 
-      <para>This <filename>/etc/krb5.conf</filename> implies that the
+      <para>In this example, the
 	<acronym>KDC</acronym> will use the fully-qualified hostname
 	<systemitem
 	  class="fqdomainname">kerberos.example.org</systemitem>.  Add
-	a CNAME (alias) entry to the zone file to accomplish this
-	if the <acronym>KDC</acronym> has a different hostname.</para>
+	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>
 
-      <note>
 	<para>For large networks with a properly configured
 	  <acronym>DNS</acronym> server, the above example could be
 	  trimmed to:</para>
 
 	<programlisting>[libdefaults]
-      default_realm = EXAMPLE.ORG</programlisting>
+      default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
 
 	<para>With the following lines being appended to the
 	  <systemitem
 	    class="fqdomainname">example.org</systemitem> zone
 	  file:</para>
 
-	<programlisting>_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
-_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
-_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
-_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
-_kerberos           IN  TXT     EXAMPLE.ORG</programlisting>
-      </note>
+	<programlisting>_kerberos._udp      IN  SRV     01 00 88 <replaceable>kerberos.example.org</replaceable>.
+_kerberos._tcp      IN  SRV     01 00 88 <replaceable>kerberos.example.org</replaceable>.
+_kpasswd._udp       IN  SRV     01 00 464 <replaceable>kerberos.example.org</replaceable>.
+_kerberos-adm._tcp  IN  SRV     01 00 749 <replaceable>kerberos.example.org</replaceable>.
+_kerberos           IN  TXT     <replaceable>EXAMPLE.ORG</replaceable></programlisting>
 
       <note>
-	<para>For clients to be able to find the
-	  <application>Kerberos</application> services, it
+	<para>In order for clients to be able to find the
+	  <application>Kerberos</application> services, the <acronym>KDC</acronym>
 	  <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 DNS
+	  <emphasis>and</emphasis> a properly configured <acronym>DNS</acronym>
 	  server.</para>
       </note>
 
       <para>Next, create the <application>Kerberos</application>
-	database which contains the keys of all principals encrypted
+	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 &man.kstash.8; and enter a password.</para>
+	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>
 
       <para>Once the master key has been created, initialize the
 	database using <command>kadmin -l</command>.  This option
-	instructs &man.kadmin.8; to modify the local database files
+	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 before it is created.  At the
-	&man.kadmin.8; prompt, use <command>init</command> to create
-	the realm's initial database.</para>
+	<command>kadmin</command> prompt, use <command>init</command> to create
+	the realm's initial database:</para>
+
+      <screen>&prompt.root; <userinput>kadmin -l</userinput>
+kadmin> <userinput>init <replaceable>EXAMPLE.ORG</replaceable></userinput>
+Realm max ticket life [unlimited]:</screen>
 
-      <para>Lastly, while still in &man.kadmin.8;, create the first
+      <para>Lastly, while still in <command>kadmin</command>, create the first
 	principal using <command>add</command>.  Stick to the default
 	options for the principal for now, as these can be changed
 	later with <command>modify</command>.  Type
-	<literal>?</literal> at the &man.kadmin.8; prompt to see the
+	<literal>?</literal> at the prompt to see the
 	available options.</para>
 
-      <para>A sample database creation session is shown below:</para>
-
-      <screen>&prompt.root; <userinput>kstash</userinput>
-Master key: <userinput>xxxxxxxx</userinput>
-Verifying password - Master key: <userinput>xxxxxxxx</userinput>
-
-&prompt.root; <userinput>kadmin -l</userinput>
-kadmin> <userinput>init EXAMPLE.ORG</userinput>
-Realm max ticket life [unlimited]:
-kadmin> <userinput>add tillman</userinput>
+      <screen>kadmin> <userinput>add <replaceable>tillman</replaceable></userinput>
 Max ticket life [unlimited]:
 Max renewable life [unlimited]:
 Attributes []:
-Password: <userinput>xxxxxxxx</userinput>
-Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
+Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
+Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
 
-      <para>Next, start the <acronym>KDC</acronym> services.  Run
+      <para>Next, start the <acronym>KDC</acronym> services by running
 	<command>service kerberos start</command> and
-	<command>service kadmind start</command> to bring up the
-	services.  While there will not be any kerberized daemons
+	<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 (user) that was just
-	created from the command-line of the <acronym>KDC</acronym>
-	itself:</para>
+	listing a ticket for the principal that was just
+	created from the command-line of the <acronym>KDC</acronym>:</para>
 
       <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
 tillman at EXAMPLE.ORG's Password:
 
 &prompt.user; <userinput>klist</userinput>
-Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
+Credentials cache: FILE:/tmp/krb5cc_500
 	Principal: tillman at EXAMPLE.ORG
 
   Issued           Expires          Principal
 Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG at EXAMPLE.ORG</screen>
 
-      <para>The ticket can then be revoked when finished:</para>
+      <para>The temporary ticket can be revoked when the test is finished:</para>
 
       <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
     </sect2>
 
     <sect2>
-      <title><application>Kerberos</application> Enabling a Server
-	with Heimdal Services</title>
+      <title>Configuring a Server to use
+	<application>Kerberos</application></title>
 
       <indexterm>
 	<primary>Kerberos5</primary>
 	<secondary>enabling services</secondary>
       </indexterm>
 
-      <para>First, copy
+      <para>To configure a server to use
+	<application>Kerberos</application> authentication, copy
 	<filename>/etc/krb5.conf</filename> from the
-	<acronym>KDC</acronym> to the client computer in a secure
+	<acronym>KDC</acronym> to the server in a secure
 	fashion, such as &man.scp.1;, or physically via removable
 	media.</para>
 
-      <para>Next, create <filename>/etc/krb5.keytab</filename>.
+      <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
@@ -1323,20 +1297,18 @@ Aug 27 15:37:58  Aug 28 01:37:58  krbtgt
 	<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.</para>
-
-      <para>Typically, the <filename>keytab</filename> is transferred
-	to the server using &man.kadmin.8;.  This is handy because the
+	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
-	&man.kadmin.8;.</para>
+	<command>kadmin</command>.</para>
 
-      <para>A ticket must already be obtained and this ticket must be
-	allowed to use the &man.kadmin.8; interface in the
+      <para>A ticket must first be obtained and this ticket must be
+	allowed to use the <command>kadmin</command> interface in the
 	<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
-	lists.  Instead of enabling remote &man.kadmin.8; access, the
+	lists.  Instead of enabling remote <command>kadmin</command> access, the
 	administrator can securely connect to the
 	<acronym>KDC</acronym> via the local console or &man.ssh.1;,
 	and perform administration locally using
@@ -1346,15 +1318,14 @@ Aug 27 15:37:58  Aug 28 01:37:58  krbtgt
 	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.  For
-	example:</para>
+	to extract the server's host principal to its own keytab:</para>
 
       <screen>&prompt.root; <userinput>kadmin</userinput>
 kadmin><userinput> add --random-key host/myserver.example.org</userinput>
 Max ticket life [unlimited]:
 Max renewable life [unlimited]:
 Attributes []:
-kadmin><userinput> ext host/myserver.example.org</userinput>
+kadmin><userinput> ext <replaceable>host/myserver.example.org</replaceable></userinput>
 kadmin><userinput> exit</userinput></screen>
 
       <para>Note that <command>ext</command> stores the extracted key
@@ -1362,15 +1333,14 @@ kadmin><userinput> exit</userinput></
 
       <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 host principal (<systemitem
-	  class="username">host/myserver.EXAMPLE.ORG</systemitem>)
+	&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>, using something like this:</para>
+	<acronym>KDC</acronym>:</para>
 
       <screen>&prompt.root; <userinput>kadmin</userinput>
-kadmin><userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
+kadmin><userinput> ext --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput>
 kadmin><userinput> exit</userinput></screen>
 
       <para>The keytab can then be securely copied to the server


More information about the svn-doc-all mailing list