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

Warren Block <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.doc
Message-ID <[email protected]>
Author: wblock
Date: Sun May 25 20:55:35 2014
New Revision: 44952
URL: http://svnweb.freebsd.org/changeset/doc/44952

Log:
  Whitespace-only fixes.  Translators, please ignore.

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	Sun May 25 16:32:53 2014	(r44951)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Sun May 25 20:55:35 2014	(r44952)
@@ -4,7 +4,10 @@
 
      $FreeBSD$
 -->
-<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
+<chapter xmlns="http://docbook.org/ns/docbook"
+  xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
+  xml:id="security">
+
   <info>
     <title>Security</title>
 
@@ -1083,35 +1086,46 @@ sendmail : PARANOID : deny</programlisti
       <title><application>Kerberos</application></title>
 
       <authorgroup>
-	<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed
-	  by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Tillman</firstname>
+	    <surname>Hodgson</surname>
+	  </personname>
+	  <contrib>Contributed by </contrib>
+	</author>
       </authorgroup>
+
       <authorgroup>
-	<author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>Based
-	  on a contribution by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Mark</firstname>
+	    <surname>Murray</surname>
+	  </personname>
+	  <contrib>Based on a contribution by </contrib>
+	</author>
       </authorgroup>
     </info>
 
     <para><application>Kerberos</application> is a network
       authentication protocol which was originally created by the
-      Massachusetts Institute of Technology
-      (<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 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
-      <application>Kerberos</application>, their communications can be
-      encrypted to assure privacy and data integrity.</para>
+      Massachusetts Institute of Technology (<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 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 <application>Kerberos</application>, their
+      communications can be encrypted to assure privacy and data
+      integrity.</para>
 
     <para>The only function of <application>Kerberos</application> is
-      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>
+      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;4120.  Several free
@@ -1123,18 +1137,20 @@ sendmail : PARANOID : deny</programlisti
       <acronym>US</acronym> export regulations.  In &os;,
       <acronym>MIT</acronym> <application>Kerberos</application> is
       available as the <package>security/krb5</package> package or
-      port.  The Heimdal <application>Kerberos</application> implementation was
-      explicitly developed outside of the <acronym>US</acronym> to
-      avoid export regulations.  The Heimdal
+      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 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
+      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>
 
@@ -1177,14 +1193,15 @@ sendmail : PARANOID : deny</programlisti
 
       <para>The Key Distribution Center (<acronym>KDC</acronym>) is
 	the centralized authentication service that
-	<application>Kerberos</application> provides, the <quote>trusted
-	  third party</quote> of the system.  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, 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, it has heightened security
-	concerns.  Direct access to the KDC should be limited.</para>
+	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, 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
@@ -1219,9 +1236,9 @@ kadmind5_server_enable="YES"</programlis
       <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>
+	<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>
@@ -1252,22 +1269,22 @@ _kerberos           IN  TXT     <replace
 	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>; 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>
+	<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>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
 Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
 
-      <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
+      <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>
@@ -1299,10 +1316,11 @@ Verifying password - Password: <userinpu
 	principal that was just created:</para>
 
       <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
[email protected]'s Password:
-</screen>
[email protected]'s Password:</screen>
+
       <para>Confirm that a ticket was successfully obtained using
-      <command>klist</command>:</para>
+	<command>klist</command>:</para>
+
       <screen>&prompt.user; <userinput>klist</userinput>
 Credentials cache: FILE:/tmp/krb5cc_1001
 	Principal: [email protected]
@@ -1333,49 +1351,52 @@ Aug 27 15:37:58 2013  Aug 28 01:37:58 20
 	regenerated on the new system.</para>
 
       <para>Next, create <filename>/etc/krb5.keytab</filename> on 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
+	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 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
+	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>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 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>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 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> 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>
+	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>
@@ -1387,11 +1408,12 @@ Attributes []:
 kadmin&gt;<userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput>
 kadmin&gt;<userinput> exit</userinput></screen>
 
-      <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
+      <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>
@@ -1400,23 +1422,25 @@ kadmin&gt;<userinput> exit</userinput></
 
       <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 inserting unneeded keys into the
-	system's keytab.</para>
+	non-default keytab name to avoid inserting unneeded keys into
+	the system's keytab.</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
+      <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>
+	<filename>/etc/ssh/sshd_config</filename>, add the
+	line:</para>
 
       <programlisting>GSSAPIAuthentication yes</programlisting>
 
-      <para>After making this change, &man.sshd.8; must be restared for
-	the new configuration to take effect: <command>service sshd
-	restart</command>.</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>
@@ -1428,34 +1452,35 @@ kadmin&gt;<userinput> exit</userinput></
 	<secondary>configure clients</secondary>
       </indexterm>
 
-      <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>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 a ticket
-	for an existing 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>.  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>
+	<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 no
 	sensitive information is sent in the clear.</para>
 
       <para>Various <application>Kerberos</application> client
-	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>
+	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>
@@ -1514,8 +1539,8 @@ [email protected]</screen>
 	<acronym>MIT</acronym> versions if <envar>PATH</envar> lists
 	the system directories first.</para>
 
-      <para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;,
-	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"
@@ -1536,9 +1561,9 @@ kadmind5_server_enable="YES"</programlis
       <itemizedlist>
 	<listitem>
 	  <para>When using either Heimdal or <acronym>MIT</acronym>
-	    <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>
+	    <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>
 
 	<listitem>
@@ -1580,15 +1605,16 @@ kadmind5_server_enable="YES"</programlis
 
 	<listitem>
 	  <para>With <acronym>MIT</acronym>
-	    <application>Kerberos</application>, to allow a
-	    principal to have a ticket life longer than the default
-	    lifetime of ten hours, use <command>modify_principal</command>
-	    at the &man.kadmin.8; prompt to change the
+	    <application>Kerberos</application>, to allow a principal
+	    to have a ticket life longer than the default 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
-	    principal can then use <command>kinit -l</command> to
-	    request a ticket with a longer lifetime.</para>
+	    question and the
+	    <systemitem class="username">krbtgt</systemitem>
+	    principal.  The principal can then use
+	    <command>kinit -l</command> to request a ticket with a
+	    longer lifetime.</para>
 	</listitem>
 
 	<listitem>
@@ -1994,21 +2020,39 @@ Connection closed by foreign host.</scre
 
   <sect1 xml:id="ipsec">
     <info>
-    <title><acronym>VPN</acronym> over
-      <acronym>IPsec</acronym></title>
+      <title><acronym>VPN</acronym> over
+	<acronym>IPsec</acronym></title>
 
       <authorgroup>
-	<author><personname><firstname>Nik</firstname><surname>Clayton</surname></personname><affiliation>
-	    <address><email>[email protected]</email></address>
-	  </affiliation><contrib>Written by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Nik</firstname>
+	    <surname>Clayton</surname>
+	  </personname>
+	  <affiliation>
+	    <address>
+	      <email>[email protected]</email>
+	    </address>
+	  </affiliation>
+	  <contrib>Written by </contrib>
+	</author>
       </authorgroup>
-	<authorgroup>
-	  <author><personname><firstname>Hiten
-	    M.</firstname><surname>Pandya</surname></personname><affiliation>
-	      <address><email>[email protected]</email></address>
-	    </affiliation><contrib>Written by </contrib></author>
-	</authorgroup>
-      </info>
+
+      <authorgroup>
+	<author>
+	  <personname>
+	    <firstname>Hiten M.</firstname>
+	    <surname>Pandya</surname>
+	  </personname>
+	  <affiliation>
+	    <address>
+	      <email>[email protected]</email>
+	    </address>
+	  </affiliation>
+	  <contrib>Written by </contrib>
+	</author>
+      </authorgroup>
+    </info>
 
     <indexterm>
       <primary><acronym>IPsec</acronym></primary>
@@ -2152,13 +2196,22 @@ device    crypto</screen>
 
     <sect2>
       <info>
-      <title>Configuring a <acronym>VPN</acronym> on &os;</title>
+	<title>Configuring a <acronym>VPN</acronym> on &os;</title>
 
-	  <authorgroup>
-	    <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><affiliation>
-		<address><email>[email protected]</email></address>
-	      </affiliation><contrib>Written by </contrib></author>
-	  </authorgroup>
+	<authorgroup>
+	  <author>
+	    <personname>
+	      <firstname>Tom</firstname>
+	      <surname>Rhodes</surname>
+	    </personname>
+	    <affiliation>
+	      <address>
+		<email>[email protected]</email>
+	      </address>
+	    </affiliation>
+	    <contrib>Written by </contrib>
+	  </author>
+	</authorgroup>
       </info>
 
       <para>To begin, <package>security/ipsec-tools</package> must be
@@ -2457,7 +2510,7 @@ racoon_enable="yes"</programlisting>
       authentication and encryption methods to prevent this from
       happening.  More information about
       <application>OpenSSH</application> is available from <link
-	  xlink:href="http://www.openssh.com/">http://www.openssh.com/</link>.</para>
+	xlink:href="http://www.openssh.com/">http://www.openssh.com/</link>.</para>
 
     <para>This section provides an overview of the built-in client
       utilities to securely access other systems and securely transfer
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.