From owner-svn-doc-all@FreeBSD.ORG Fri Apr 4 14:30:08 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17510B52; Fri, 4 Apr 2014 14:30:08 +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 EE1CA649; Fri, 4 Apr 2014 14:30:07 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s34EU7gO026424; Fri, 4 Apr 2014 14:30:07 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s34EU7vU026423; Fri, 4 Apr 2014 14:30:07 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404041430.s34EU7vU026423@svn.freebsd.org> From: Dru Lavigne Date: Fri, 4 Apr 2014 14:30:07 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44442 - 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.17 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: Fri, 04 Apr 2014 14:30:08 -0000 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 section of - the handbook. Kerberose users may need to make additional + the handbook. Kerberos users may need to make additional changes to implement OpenSSH in their network. @@ -1050,7 +1050,7 @@ sendmail : PARANOID : deny - <application>Kerberos5</application> + <application>Kerberos</application> TillmanHodgsonContributed @@ -1062,11 +1062,15 @@ sendmail : PARANOID : deny - Kerberos is a network add-on - system/protocol that allows users to authenticate themselves - through the services of a secure server. + Kerberos is a network + authentication protocol which was originally created by the + Massachusetts Institute of Technology + (MIT) as a solution to network security + problems. The Kerberos protocol uses + strong cryptography so that both a client and server can prove + their identity over an insecure network. Kerberos 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 Kerberos, their communications can be encrypted to assure privacy and data @@ -1074,24 +1078,42 @@ sendmail : PARANOID : denyThe only function of Kerberos 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 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 1510. Several free + implementations of this protocol are + available, covering a wide range of operating systems. + MIT + continues to develop their Kerberos + package. It is commonly used in the US as + a cryptography product, and has historically been affected by + US export regulations. In &os;, + MIT Kerberos is + available as the security/krb5 package or + port. Heimdal Kerberos + was explicitly developed outside + of the US to avoid export regulations. The + Heimdal Kerberos distribution is + available as the security/heimdal package + or port, and a minimal installation is included in the base + &os; install. + This section provides a guide on how to set up - Kerberos as distributed for &os;. - Refer to the relevant manual pages for more complete - descriptions. + Kerberos using the Heimdal + distribution included in &os;. For purposes of demonstrating a - Kerberos installation, the various + Kerberos installation, the name spaces will be as follows: - The DNS domain (zone) + The DNS domain (zone) will be example.org. @@ -1104,58 +1126,13 @@ sendmail : PARANOID : deny Use real domain names when setting up - Kerberos even if it will run + Kerberos, even if it will run internally. This avoids DNS problems and assures inter-operation with other Kerberos realms. - History - - - Kerberos5 - history - - - Kerberos was created by - MIT as a solution to network security - problems. The Kerberos protocol - uses strong cryptography so that a client can prove its - identity to a server (and vice versa) across an insecure - network connection. - - Kerberos is both the name of a - network authentication protocol and an adjective to describe - programs that implement it, such as - Kerberos telnet. The current - version of the protocol is version 5, described in - RFC 1510. - - Several free implementations of this protocol are - available, covering a wide range of operating systems. The - Massachusetts Institute of Technology - (MIT), where - Kerberos was originally developed, - continues to develop their Kerberos - package. It is commonly used in the US as - a cryptography product, and has historically been affected by - US export regulations. The - MIT Kerberos is - available as the security/krb5 package or - port. Heimdal Kerberos is another - version 5 implementation, and was explicitly developed outside - of the US to avoid export regulations. The - Heimdal Kerberos distribution is - available as a the security/heimdal package - or port, and a minimal installation is included in the base - &os; install. - - These instructions assume the use of the Heimdal - distribution included in &os;. - - - Setting up a Heimdal <acronym>KDC</acronym> @@ -1168,19 +1145,17 @@ sendmail : PARANOID : denyKerberos provides. It is the computer that issues Kerberos tickets. The KDC is considered - trusted by all other computers in the + trusted by all other computers in the Kerberos realm, and thus has heightened security concerns. - While running the Kerberos - server requires very few computing resources, a dedicated + While running a KDC + requires few computing resources, a dedicated machine acting only as a KDC is recommended for security reasons. - To begin setting up a KDC, ensure that - /etc/rc.conf contains the correct - settings to act as a KDC. As required, - adjust paths to reflect the system: + To begin setting up a KDC, add these lines to + /etc/rc.conf: kerberos5_server_enable="YES" kadmind5_server_enable="YES" @@ -1189,132 +1164,131 @@ kadmind5_server_enable="YES" [libdefaults] - default_realm = EXAMPLE.ORG + default_realm = EXAMPLE.ORG [realms] - EXAMPLE.ORG = { - kdc = kerberos.example.org - admin_server = kerberos.example.org + EXAMPLE.ORG = { + kdc = kerberos.example.org + admin_server = kerberos.example.org } [domain_realm] - .example.org = EXAMPLE.ORG + .example.org = EXAMPLE.ORG - This /etc/krb5.conf implies that the + In this example, the KDC will use the fully-qualified hostname kerberos.example.org. Add - a CNAME (alias) entry to the zone file to accomplish this - if the KDC has a different hostname. + a CNAME entry to the DNS zone file + if the KDC has a different hostname than + that specified in /etc/krb5.conf. - For large networks with a properly configured DNS server, the above example could be trimmed to: [libdefaults] - default_realm = EXAMPLE.ORG + default_realm = EXAMPLE.ORG With the following lines being appended to the example.org zone file: - _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 - + _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 - For clients to be able to find the - Kerberos services, it + In order for clients to be able to find the + Kerberos services, the KDC must have either a fully configured /etc/krb5.conf or a minimally configured /etc/krb5.conf - and a properly configured DNS + and a properly configured DNS server. Next, create the Kerberos - 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 /var/heimdal/m-key. To create the - master key, run &man.kstash.8; and enter a password. + master key, run kstash and enter a password: + + &prompt.root; kstash +Master key: xxxxxxxx +Verifying password - Master key: xxxxxxxx Once the master key has been created, initialize the database using kadmin -l. This option - instructs &man.kadmin.8; to modify the local database files + instructs kadmin 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 init to create - the realm's initial database. + kadmin prompt, use init to create + the realm's initial database: + + &prompt.root; kadmin -l +kadmin> init EXAMPLE.ORG +Realm max ticket life [unlimited]: - Lastly, while still in &man.kadmin.8;, create the first + Lastly, while still in kadmin, create the first principal using add. Stick to the default options for the principal for now, as these can be changed later with modify. Type - ? at the &man.kadmin.8; prompt to see the + ? at the prompt to see the available options. - A sample database creation session is shown below: - - &prompt.root; kstash -Master key: xxxxxxxx -Verifying password - Master key: xxxxxxxx - -&prompt.root; kadmin -l -kadmin> init EXAMPLE.ORG -Realm max ticket life [unlimited]: -kadmin> add tillman + kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: -Password: xxxxxxxx -Verifying password - Password: xxxxxxxx +Password: xxxxxxxx +Verifying password - Password: xxxxxxxx - Next, start the KDC services. Run + Next, start the KDC services by running service kerberos start and - service kadmind start to bring up the - services. While there will not be any kerberized daemons + service kadmind start. + While there will not be any kerberized daemons running at this point, it is possible to confirm that the KDC is functioning by obtaining and - listing a ticket for the principal (user) that was just - created from the command-line of the KDC - itself: + listing a ticket for the principal that was just + created from the command-line of the KDC: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist -Credentials cache: FILE:/tmp/krb5cc_500 +Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG - The ticket can then be revoked when finished: + The temporary ticket can be revoked when the test is finished: &prompt.user; kdestroy - <application>Kerberos</application> Enabling a Server - with Heimdal Services + Configuring a Server to use + <application>Kerberos</application> Kerberos5 enabling services - First, copy + To configure a server to use + Kerberos authentication, copy /etc/krb5.conf from the - KDC to the client computer in a secure + KDC to the server in a secure fashion, such as &man.scp.1;, or physically via removable media. - Next, create /etc/krb5.keytab. + Next, create /etc/krb5.keytab on the + server. This is the major difference between a server providing Kerberos 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 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 transferred - to the server using &man.kadmin.8;. This is handy because the + public. Typically, the keytab is transferred + to the server using kadmin. This is handy because the host principal, the KDC end of the krb5.keytab, is also created using - &man.kadmin.8;. + kadmin. - A ticket must already be obtained and this ticket must be - allowed to use the &man.kadmin.8; interface in the + A ticket must first be obtained and this ticket must be + allowed to use the kadmin interface in the kadmind.acl. See the section titled - Remote administration ininfo + Remote administration in info heimdal for details on designing access control - lists. Instead of enabling remote &man.kadmin.8; access, the + lists. Instead of enabling remote kadmin access, the administrator can securely connect to the KDC 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 add --random-key from the Kerberos server. This adds the server's host principal. Then, use ext - to extract the server's host principal to its own keytab. For - example: + to extract the server's host principal to its own keytab: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: -kadmin> ext host/myserver.example.org +kadmin> ext host/myserver.example.org kadmin> exit Note that ext stores the extracted key @@ -1362,15 +1333,14 @@ kadmin> exitIf &man.kadmind.8; is not running on the KDC and there is no access to - &man.kadmin.8; remotely, add the host principal (host/myserver.EXAMPLE.ORG) + &man.kadmin.8; remotely, add the server's host principal directly on the KDC and then extract it to a temporary file to avoid overwriting the /etc/krb5.keytab on the - KDC, using something like this: + KDC: &prompt.root; kadmin -kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org +kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit The keytab can then be securely copied to the server