From owner-svn-doc-all@FreeBSD.ORG Sun May 25 20:55:36 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63B19704; Sun, 25 May 2014 20:55:36 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4466120FC; Sun, 25 May 2014 20:55:36 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s4PKta8o062300; Sun, 25 May 2014 20:55:36 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s4PKta4V062299; Sun, 25 May 2014 20:55:36 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201405252055.s4PKta4V062299@svn.freebsd.org> From: Warren Block Date: Sun, 25 May 2014 20:55:36 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44952 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 20:55:36 -0000 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$ --> - + + Security @@ -1083,35 +1086,46 @@ sendmail : PARANOID : denyKerberos - TillmanHodgsonContributed - by + + + Tillman + Hodgson + + Contributed by + + - MarkMurrayBased - on a contribution by + + + Mark + Murray + + Based on a contribution by + Kerberos is a network authentication protocol which was originally created by the - Massachusetts Institute of Technology - (MIT) as a way to securely provide authentication - across a potentially hostile network. - The Kerberos protocol uses - strong cryptography so that both a client and server can prove - their identity without sending any unencrypted secrets over the network. - Kerberos can be described as an - identity-verifying proxy system and as a trusted third-party - authentication system. After a user authenticates with - Kerberos, their communications can be - encrypted to assure privacy and data integrity. + Massachusetts Institute of Technology (MIT) + as a way to securely provide authentication across a potentially + hostile network. The Kerberos + protocol uses strong cryptography so that both a client and + server can prove their identity without sending any unencrypted + secrets over the network. Kerberos + can be described as an identity-verifying proxy system and as a + trusted third-party authentication system. After a user + authenticates with Kerberos, their + communications can be encrypted to assure privacy and data + integrity. The only function of Kerberos 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 Kerberos be used - with other security methods which provide authorization and - audit services. + to provide the secure authentication of users and servers on the + network. It does not provide authorization or auditing + functions. It is recommended that + Kerberos be used with other security + methods which provide authorization and audit services. The current version of the protocol is version 5, described in RFC 4120. Several free @@ -1123,18 +1137,20 @@ sendmail : PARANOID : denyUS export regulations. In &os;, MIT Kerberos is available as the security/krb5 package or - port. The Heimdal Kerberos implementation was - explicitly developed outside of the US to - avoid export regulations. The Heimdal + port. The Heimdal Kerberos + implementation was explicitly developed outside of the + US to avoid export regulations. The Heimdal Kerberos distribution is included in the base &os; installation, and another distribution with more - configurable options is available as security/heimdal - in the Ports Collection. - - In Kerberos users and services are - identified as principals which are contained within - an administrative grouping, called a realm. A - typical user principal would be of the form + configurable options is available as + security/heimdal in the Ports + Collection. + + In Kerberos users and services + are identified as principals which are contained + within an administrative grouping, called a + realm. A typical user principal would be of the + form user@REALM (realms are traditionally uppercase). @@ -1177,14 +1193,15 @@ sendmail : PARANOID : denyThe Key Distribution Center (KDC) is the centralized authentication service that - Kerberos provides, the trusted - third party of the system. It is the + Kerberos provides, the + trusted third party of the system. It is the computer that issues Kerberos - tickets, which are used for clients to authenticate to servers. - Because the KDC is considered trusted by - all other computers in the - Kerberos realm, it has heightened security - concerns. Direct access to the KDC should be limited. + tickets, which are used for clients to authenticate to + servers. Because the KDC is considered + trusted by all other computers in the + Kerberos realm, it has heightened + security concerns. Direct access to the KDC should be + limited. While running a KDC requires few computing resources, a dedicated machine acting only as a @@ -1219,9 +1236,9 @@ kadmind5_server_enable="YES"Kerberos can also use the DNS to locate KDCs, instead of a [realms] section in - /etc/krb5.conf. For large organizations that - have their own DNS servers, the above example - could be trimmed to: + /etc/krb5.conf. For large organizations + that have their own DNS servers, the above + example could be trimmed to: [libdefaults] default_realm = EXAMPLE.ORG @@ -1252,22 +1269,22 @@ _kerberos IN TXT /var/heimdal/m-key; it would be reasonable to - use a 45-character random password for this purpose. To create the - master key, run kstash and enter a - password: + /var/heimdal/m-key; it would be + reasonable to use a 45-character random password for this + purpose. To create the master key, run + kstash and enter a password: &prompt.root; kstash Master key: xxxxxxxxxxxxxxxxxxxxxxx Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx - Once the master key has been created, the database should be - initialized. The Kerberos 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 kadmin -l. - This resolves the chicken-and-egg problem of trying to connect to - the database + Once the master key has been created, the database should + be initialized. The Kerberos + 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 + kadmin -l. This resolves the + chicken-and-egg problem of trying to connect to the database before it is created. At the kadmin prompt, use init to create the realm's initial database: @@ -1299,10 +1316,11 @@ Verifying password - Password: &prompt.user; kinit tillman -tillman@EXAMPLE.ORG's Password: - +tillman@EXAMPLE.ORG's Password: + Confirm that a ticket was successfully obtained using - klist: + klist: + &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: tillman@EXAMPLE.ORG @@ -1333,49 +1351,52 @@ Aug 27 15:37:58 2013 Aug 28 01:37:58 20 regenerated on the new system. Next, create /etc/krb5.keytab on the - server. This is the main part of Kerberizing a service - — it corresponds to generating a secret shared between the - service and the KDC. The secret is a cryptographic - key, stored in a keytab. The keytab contains - the server's host key, which allows it and the KDC - 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 Kerberizing a + service — it corresponds to generating a secret shared + between the service and the KDC. The + secret is a cryptographic key, stored in a + keytab. The keytab contains the server's host + key, which allows it and the KDC 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 keytab is generated on an administrator's trusted machine using kadmin, 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 kadmin on the - server directly is convenient, because the entry for the host - principal in the KDC database is also created using + the key is known by some other party, that party can + impersonate any user to the server! Using + kadmin on the server directly is + convenient, because the entry for the host principal in the + KDC database is also created using kadmin. - Of course, kadmin is a kerberized service; - a Kerberos ticket is needed to authenticate - to the network service, but to ensure that the user running - kadmin is actually present (and their session has - not been hijacked), kadmin will prompt for the - password to get a fresh ticket. The principal authenticating - to the kadmin service must be permitted to use the - kadmin interface, as specified in - kadmind.acl. See the section titled - Remote administration in info - heimdal for details on designing access control - lists. Instead of enabling remote kadmin - access, the administrator could securely connect to the - KDC via the local console or &man.ssh.1;, - and perform administration locally using - kadmin -l. + Of course, kadmin is a kerberized + service; a Kerberos ticket is + needed to authenticate to the network service, but to ensure + that the user running kadmin is actually + present (and their session has not been hijacked), + kadmin will prompt for the password to get + a fresh ticket. The principal authenticating to the kadmin + service must be permitted to use the kadmin + interface, as specified in kadmind.acl. + See the section titled Remote administration in + info heimdal for details on designing + access control lists. Instead of enabling remote + kadmin access, the administrator could + securely connect to the KDC via the local + console or &man.ssh.1;, and perform administration locally + using kadmin -l. After installing /etc/krb5.conf, - use add --random-key in kadmin. - 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 ext to extract the server's host - principal key to its own keytab: + use add --random-key in + kadmin. 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 + ext to extract the server's host principal + key to its own keytab: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org @@ -1387,11 +1408,12 @@ Attributes []: kadmin> ext_keytab host/myserver.example.org kadmin> exit - Note that ext_keytab stores the extracted key - in /etc/krb5.keytab by default. This is - good when being run on the server being kerberized, but the - --keytab path/to/file - argument should be used when the keytab is being extracted + Note that ext_keytab stores the + extracted key in /etc/krb5.keytab by + default. This is good when being run on the server being + kerberized, but the --keytab + path/to/file argument + should be used when the keytab is being extracted elsewhere: &prompt.root; kadmin @@ -1400,23 +1422,25 @@ kadmin> exitThe 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. + non-default keytab name to avoid inserting unneeded keys into + the system's keytab. - At this point, the server can read encrypted messages from the - KDC using its shared key, stored in - krb5.keytab. It is now - ready for the Kerberos-using services to - be enabled. One of the most common such services is &man.sshd.8;, - which supports Kerberos via the + At this point, the server can read encrypted messages from + the KDC using its shared key, stored in + krb5.keytab. It is now ready for the + Kerberos-using services to be + enabled. One of the most common such services is + &man.sshd.8;, which supports + Kerberos via the GSS-API. In - /etc/ssh/sshd_config, add the line: + /etc/ssh/sshd_config, add the + line: GSSAPIAuthentication yes - After making this change, &man.sshd.8; must be restared for - the new configuration to take effect: service sshd - restart. + After making this change, &man.sshd.8; must be restared + for the new configuration to take effect: + service sshd restart. @@ -1428,34 +1452,35 @@ kadmin> exitconfigure clients - As it was for the server, the client requires configuration in - /etc/krb5.conf. Copy the file in place - (securely) or re-enter it as needed. + As it was for the server, the client requires + configuration in /etc/krb5.conf. Copy + the file in place (securely) or re-enter it as needed. Test the client by using kinit, klist, and kdestroy from - the client to obtain, show, and then delete a ticket - for an existing principal. Kerberos + the client to obtain, show, and then delete a ticket for an + existing principal. Kerberos applications should also be able to connect to Kerberos 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 - KDC. In the case of kerberized &man.ssh.1;, - GSS-API is disabled by default, so test using - ssh -o GSSAPIAuthentication=yes - hostname. + KDC. In the case of kerberized + &man.ssh.1;, GSS-API is disabled by + default, so test using ssh -o + GSSAPIAuthentication=yes + hostname. When testing a Kerberized application, try using a packet sniffer such as tcpdump to confirm that no sensitive information is sent in the clear. Various Kerberos client - applications are available. With the advent of a bridge so that - applications using SASL for authentication can - use GSS-API mechanisms as well, large classes - of client applications can use Kerberos - for authentication, from Jabber clients to IMAP - clients. + applications are available. With the advent of a bridge so + that applications using SASL for + authentication can use GSS-API mechanisms + as well, large classes of client applications can use + Kerberos for authentication, from + Jabber clients to IMAP clients. .k5login @@ -1514,8 +1539,8 @@ jdoe@example.org MIT versions if PATH lists the system directories first. - When using MIT Kerberos as a KDC on &os;, - the following edits should also be made to + When using MIT Kerberos as a KDC on + &os;, the following edits should also be made to rc.conf: kerberos5_server="/usr/local/sbin/krb5kdc" @@ -1536,9 +1561,9 @@ kadmind5_server_enable="YES" When using either Heimdal or MIT - Kerberos from ports, ensure that the - PATH lists the port's versions of the - client applications before the system versions. + Kerberos from ports, ensure + that the PATH lists the port's versions of + the client applications before the system versions. @@ -1580,15 +1605,16 @@ kadmind5_server_enable="YES" With MIT - Kerberos, to allow a - principal to have a ticket life longer than the default - lifetime of ten hours, use modify_principal - at the &man.kadmin.8; prompt to change the + Kerberos, to allow a principal + to have a ticket life longer than the default lifetime of + ten hours, use modify_principal at the + &man.kadmin.8; prompt to change the maxlife of both the principal in - question and the krbtgt principal. The - principal can then use kinit -l to - request a ticket with a longer lifetime. + question and the + krbtgt + principal. The principal can then use + kinit -l to request a ticket with a + longer lifetime. @@ -1994,21 +2020,39 @@ Connection closed by foreign host. - <acronym>VPN</acronym> over - <acronym>IPsec</acronym> + <acronym>VPN</acronym> over + <acronym>IPsec</acronym> - NikClayton -
nik@FreeBSD.org
- Written by + + + Nik + Clayton + + +
+ nik@FreeBSD.org +
+ + Written by + - - Hiten - M.Pandya -
hmp@FreeBSD.org
- Written by - - + + + + + Hiten M. + Pandya + + +
+ hmp@FreeBSD.org +
+ + Written by + + + IPsec @@ -2152,13 +2196,22 @@ device crypto - Configuring a <acronym>VPN</acronym> on &os; + Configuring a <acronym>VPN</acronym> on &os; - - TomRhodes -
trhodes@FreeBSD.org
- Written by - + + + + Tom + Rhodes + + +
+ trhodes@FreeBSD.org +
+ + Written by + + To begin, security/ipsec-tools must be @@ -2457,7 +2510,7 @@ racoon_enable="yes" authentication and encryption methods to prevent this from happening. More information about OpenSSH is available from http://www.openssh.com/. + xlink:href="http://www.openssh.com/">http://www.openssh.com/. This section provides an overview of the built-in client utilities to securely access other systems and securely transfer