CSP-Kerberos™ is a set of programs and libraries that provide distributed user identification and authentication over an open network. Servers using CSP-Kerberos can be certain of the identities of clients making requests. Likewise, clients using CSP-Kerberos can be sure their requests are being serviced by authentic servers. Applications that use CSP-Kerberos distributed authentication are called kerberized applications.
This chapter contains the following major sections:
“Introduction to CSP-Kerberos”
This section briefly explains the nature of CSP-Kerberos and the software packages in this distribution.
-
This section outlines some of the user interactions with CSP-Kerberos and provides more detail on how CSP-Kerberos performs its work.
-
This section details the planning you should do before you install and configure your CSP-Kerberos software.
-
This section provides installation instructions for all classes of systems running the CSP-Kerberos software.
-
This section provides post-installation configuration advice, as well as some information about unusual configuration scenarios.
“CSP-Kerberos Administrative Commands”
This section details the administrative commands used to maintain and configure CSP-Kerberos.
-
This section briefly lists the programming libraries distributed for CSP-Kerberos custom development.
“Troubleshooting CSP-Kerberos”
This section provides troubleshooting advice for CSP-Kerberos.
This implementation of CSP-Kerberos is based on the Kerberos authentication system developed at the Massachusetts Institute of Technology. Under CSP-Kerberos, a client (generally either a user or a service) uses the kinit(1) utility to request services from the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) for the client, encrypts it using the client's password as the key, and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (that is, if the user gave the correct password), it keeps the decrypted TGT, which indicates proof of the client's identity.
The TGT, which expires at a specified time, permits the client to obtain additional tickets, which give permission for specific services. The requesting and granting of these additional tickets is transparent to the user.
As with any software package that uses a centralized database, the installation procedure is somewhat involved, and requires forethought and planning. We have attempted to make this chapter as concise as possible, rather than making it an exhaustive description of the details of CSP-Kerberos.
It is assumed in this guide that readers are familiar with the user-level CSP-Kerberos mechanism of distributed authentication, as described in the Commercial Security Pak User's Guide.
The Silicon Graphics implementation of CSP-Kerberos software is based on Kerberos version 5 (Beta 6) from MIT, and can be categorized into the following general classes of files and programs:
CSP-Kerberos KDC software
CSP-Kerberos KDC software is provided in the csp-kerberos.sw.kdc package in your software distribution.
CSP-Kerberos KDC software executes on the host that provides and manages the secure CSP-Kerberos principal database. This package includes software commonly called the ticket-granting server (TGS), the key or CSP-Kerberos distribution center (KDC), the CSP-Kerberos Name Server (KNS), and the CSP-Kerberos Database Manager (KDBM).
This software also includes the utility commands (for example, kdb5_create, kdb5_destroy, kadmin5 and kdb5_edit) that are used to manage the CSP-Kerberos principal database.
CSP-Kerberos server software
CSP-Kerberos server software is provided in the csp-kerberos.sw.server package in your distribution.
CSP-Kerberos server software includes the daemon programs, such as klogind(8), kshd(8), ftpd(8), and telnetd(8), that provide CSP-Kerberos authenticated services to requesting clients.
CSP-Kerberos client software
CSP-Kerberos client-side software is distributed in the csp-kerberos.sw.client package in your software distribution,
Kerberized client applications are client programs that obtain CSP-Kerberos authenticated services from kerberized servers. Examples of client programs are kerberized rlogin(1), rsh(1), rcp(1), ksu(1), telnet(1B), and ftp(1B).
CSP-Kerberos utility commands run on hosts from which users establish CSP-Kerberos authenticated sessions. These commands manage user tickets and allow users to change their CSP-Kerberos passwords. Examples of utilities are kinit(1), kpasswd(1), klist(1), and kdestroy(1).
CSP-Kerberos development libraries
These programming libraries are distributed in the csp-kerberos.sw.dev package in your software distribution,
CSP-Kerberos libraries are used to create and run kerberized applications. The library set includes libraries that provide assistance in obtaining and using tickets, encrypting and decrypting CSP-Kerberos data, managing CSP-Kerberos access control lists, and communicating with the CSP-Kerberos administration server.
Note: Support for data stream encryption in kerberized applications is not available outside of the United States and Canada.
Since CSP-Kerberos negotiates authenticated, and optionally encrypted, communications between two points anywhere on the internet, it provides a layer of security that is not dependent on which side of a firewall either client is on. Since studies have shown that half of the computer security breaches in industry happen from inside firewalls, you should not neglect the maintenance of security measures within your local area network or intranet.
Suppose that you walk up to a host intending to log in to it, and then rlogin to the system laughter. Here's what happens:
You log in to the workstation and use the kinit command to get a ticket-granting ticket. This command prompts you for your CSP-Kerberos password.
The kinit command sends your request to the CSP-Kerberos master server system. The server software looks for your principal name's entry in the CSP-Kerberos database.
If this entry exists, the CSP-Kerberos server creates and returns a ticket-granting ticket and the key that allows you to use it, encrypted by your password. If kinit can decrypt the CSP-Kerberos reply using the password you provide, it stores this ticket in a credentials cache on your local system for later use. The name of the credentials cache can be specified in the KRB5_CCNAME environment variable. If this variable is not set, the name of the file will be /tmp/krb5cc_<uid>, where <uid> is your IRIX user ID number.
Now you use the rlogin client to access the system laughter, as shown in the following command:
rlogin laughter
The rlogin client checks your ticket file to see if you have a ticket for the host service for laughter. You don't, so rlogin uses the credential cache's ticket-granting ticket to make a request to the master server's ticket-granting service.
This ticket-granting service receives the request for a ticket for host/laughter.yoursite.com, and looks in the master database for an entry for host/laughter.yoursite.com. If the entry exists, the ticket-granting service issues you a ticket for that service. That ticket is also cached in your credentials cache.
The rlogin client now sends that ticket to the laughter klogind service program. The service program checks the ticket by using its own service key. If the ticket is valid, it now knows your identity. If you are allowed to log in to laughter (because your username matches one in /etc/passwd, or your CSP-Kerberos principal is in the appropriate .k5login file), klogind will let you log in.
This section provides a simplified description of a general user's interaction with the CSP-Kerberos system. This interaction happens transparently, but CSP-Kerberos administrators might find a schematic description of the process useful. This description glosses over a lot of details; for more information, see “Kerberos: An Authentication Service for Open Network Systems,” a paper presented at Winter USENIX 1988, in Dallas, Texas. This paper can be retrieved by FTP from athena-dist.mit.edu, in the location /pub/ATHENA/kerberos/doc/USENIX.ps.
In an environment that provides network services, you use client programs to request services from server programs that are somewhere on the network. Suppose you have logged in to a workstation and you want to rlogin to a typical host. You use the local rlogin client program to contact the remote system's rlogind daemon.
Under CSP-Kerberos, the klogind daemon allows you to log in to a remote system if you can provide a CSP-Kerberos ticket that proves your identity. In addition to the ticket, you must also have possession of the corresponding ticket session key. The combination of a ticket and the ticket's session key is known as a credential.
Typically, a client program automatically obtains credentials identifying the person using the client program. The credentials are obtained from a CSP-Kerberos server that resides somewhere on the network. A CSP-Kerberos server maintains a database of user, server, and password information.
CSP-Kerberos gives you credentials only if you have an entry in the CSP-Kerberos server's CSP-Kerberos database. Your database entry includes your CSP-Kerberos principal (an identifying string, which is often just your username), and your CSP-Kerberos password. Every CSP-Kerberos user must have an entry in this database.
Each administrative domain has its own CSP-Kerberos database, which contains information about the users and services for that particular site or administrative domain. This administrative domain is the CSP-Kerberos realm.
Each CSP-Kerberos realm has at least one CSP-Kerberos server, where the master CSP-Kerberos database for that site or administrative domain is stored. A CSP-Kerberos realm may also have one or more slave servers, which have read-only copies of the CSP-Kerberos database that are periodically propagated from the master server. For more details on how this is done, see the “Installing CSP-Kerberos KDCs” section of this chapter.
The kinit command prompts for your password. If you enter it successfully, you obtain a ticket-granting ticket and a ticket session key, which gives you the right to use the ticket. This combination of the ticket and its associated key is known as your credentials. As illustrated below, client programs use your ticket-granting ticket credentials in order to obtain client-specific credentials as needed.
Your credentials are stored in a credentials cache, which is often just a file in /tmp. The credentials cache is also called the ticket file. Note, however, that a credentials cache does not have to be stored in a file.
The master database also contains entries for all network services that require CSP-Kerberos authentication. Suppose that your site has a system, [email protected], that requires CSP-Kerberos authentication from anyone who wants to log in to it remotely. The host's CSP-Kerberos realm is ENGR.YOURSITE.COM.
This service must be registered in the CSP-Kerberos database, using the proper service name, which in this case is the principal:
host/[email protected] |
The / character separates the CSP-Kerberos primary (in this case, host) from the instance (in this case, laughter.yoursite.com; the @ character separates the realm name (in this case, ENGR.YOURSITE.COM) from the rest of the principal. The primary, host, denotes the name or type of the service that is being offered: generic host-level access to the system. The instance, laughter.yoursite.com, names the specific system that is offering this service. There generally are many different systems, each offering one particular type of service, and the instance serves to give each one of these servers a different CSP-Kerberos principal.
Like most security precautions, some advance planning is necessary to make a successful CSP-Kerberos installation.
Because CSP-Kerberos is a complex system, customizable to your individual site needs, it is strongly recommended that you plan your CSP-Kerberos installation as outlined in the following subsections before attempting to install CSP-Kerberos on your network.
You must have at least one KDC in your CSP-Kerberos realm. Regardless of the number of KDCs you choose to have, there must be one master KDC.
Slave KDCs provide an additional source of CSP-Kerberos ticket-granting services in the event of inaccessibility of the master KDC. The number of slave KDCs you need and the decision of where to place them, both physically and logically, depend on the specifics of your network.
All of the CSP-Kerberos authentication on your network requires that each client be able to contact a KDC. Therefore, you need to anticipate any likely reason a KDC might be unavailable and have a slave KDC to take up the slack.
Some considerations include the following:
Have at least one slave KDC as a backup for when the master KDC is down, is being upgraded, or is otherwise unavailable.
If your network is split such that a network outage is likely to cause some segment or segments of the network to become cut off or isolated, have a slave KDC accessible to each segment.
If possible, have at least one slave KDC in a different building from the master, in case of power outages, fires, or other localized disasters.
Silicon Graphics recommends that your KDCs have a predefined set of hostnames, such as KDCSERVER for the master KDC and KDCSLAVE1, KDCSLAVE2, and so on for the slave KDCs. This way, if you need to swap a system, you need to change only a DNS entry, rather than the hostnames.
The CSP-Kerberos database resides on the master KDC, and must be propagated regularly (usually by a cron job) to the slave KDCs. In deciding how frequently the propagation should happen, you will need to balance the amount of time the propagation takes against the maximum reasonable amount of time a user should have to wait for a password change to take effect. Silicon Graphics recommends that this be no longer than an hour.
If the propagation time is longer than this maximum reasonable time (for example, you have a particularly large database, you have a lot of slaves, and/or you experience frequent network delays), you may wish to cut down on your propagation delay by performing the propagation in parallel. To do this, have the master KDC propagate the database to one set of slaves, and then have each of these slaves propagate the database to additional slaves.
On a CSP-Kerberos server, you must install the entire CSP-Kerberos software distribution. This includes support for kerberized servers such as ftpd, klogind, telnetd, and rshd.
If you need to install the CSP-Kerberos programs on a redundant server, you need to install CSP-Kerberos on that server and add that host to the CSP-Kerberos database. You also need to make sure the host's clock is within your maximum clock skew of the KDC. You must also generate a keytab (v5srvtab) file (using kadmin5) for that redundant server and install the keytab file on the redundant server. See “Installing CSP-Kerberos Servers” for more information.
Because the CSP-Kerberos server is the sole repository of information concerning the identities of network principals, you may want to consider installing one or more backup CSP-Kerberos servers. Backup servers allow continued use of the CSP-Kerberos authentication system if the primary CSP-Kerberos server becomes unavailable for any reason. This distribution of CSP-Kerberos includes software to propagate the CSP-Kerberos database from the primary CSP-Kerberos server to any CSP-Kerberos backup servers. This software exists as a client/server pair, kprop and kpropd.
Besides imparting the benefits of redundancy in case the primary CSP-Kerberos server is unavailable, backup servers let you configure clients and servers to query different CSP-Kerberos servers when users need to obtain tickets. Thus, additional CSP-Kerberos servers can potentially improve performance. In practice, however, the availability of multiple servers is not likely to improve performance except in very large networks. CSP-Kerberos is designed so that tickets are reusable; therefore, applications do not need to query CSP-Kerberos except when they need a new ticket. The average user might need to query CSP-Kerberos several times per day, but unless there are many users on the network, this load should not be difficult for one CSP-Kerberos server to handle.
However, if you are thinking of using backup servers, consider the trade-offs of installing redundant CSP-Kerberos servers by weighing the cost of running without CSP-Kerberos and the likelihood of primary CSP-Kerberos server failure against the extra expense and administration required to install and maintain multiple servers. Also, consider that having multiple servers means having multiple points of potential attack; all backup servers must be installed in a manner just as secure as the primary server. This includes both the physical installation, which should restrict access to the system, as well as the software installation, which must protect the security of the principal database.
On a CSP-Kerberos client, you need only install the kerberos.sw.client package of the CSP-Kerberos distribution, then make principal entries for each user on the client system on the KDC. This choice for a host provides support for authenticated outgoing CSP-kerberos sessions only. This allows users to obtain CSP-Kerberos tickets based on your system; these tickets are good for other hosts offering CSP-Kerberos authenticated services.
Although your CSP-Kerberos realm can be any ASCII string, convention is to make it the same as your domain name, in upper case letters. For example, hosts in the domain theirsite.com would be in the CSP-Kerberos realm THEIRSITE.COM.
If you need multiple CSP-Kerberos realms, Silicon Graphics recommends that you use descriptive names that end with your domain name, such as BOSTON.THEIRSITE.COM and SAN_FRANCISCO.THEIRSITE.COM.
Mapping hostnames onto CSP-Kerberos realms is done through a set of rules in the krb5.conf configuration file. You can specify mappings for an entire domain or subdomain, and/or on a hostname-by-hostname basis. Since greater specificity takes precedence, you would do this by specifying the mappings for a given domain or subdomain and listing the exceptions. Here is an example krb5.conf file:
[libdefaults]
default_realm = YOURSITE.COM
[realms]
YOURSITE.COM = {
kdc = BIGKDC.YOURSITE.COM
admin_server = SERVER.YOURSITE.COM
default_domain = YOURSITE.COM
}
[domain_realm]
yoursite.com = YOURSITE.COM
.yoursite.com = YOURSITE.COM
[login]
krb5_get_tickets = 1
krb4_get_tickets = 1
krb4_convert = 0
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
|
You may want to allow users to develop their own authenticated clients and servers. This requires that they be allowed to link their programs with CSP-Kerberos libraries. It also requires cooperation with the CSP-Kerberos administrator, who must edit the primary CSP-Kerberos database of network principals to inform CSP-Kerberos about the new servers. See “CSP-Kerberos Libraries” for more information.
Because CSP-Kerberos depends on the use of encrypted time stamps that allow it to detect replay attacks (attempts to place packets back on the network) and expired tickets (tickets that are no longer current), it is critical that all relevant hosts (clients, servers, and CSP-Kerberos servers) keep their clocks synchronized within a few seconds of each other at all times.
If the relevant hosts on your network do not have synchronized clocks, it is very likely that CSP-Kerberos authentication will fail with “Time Out Of Bounds” or “Ticket Expired” errors.
With this in mind, you should initiate procedures that will keep the system clocks synchronized on the relevant hosts before trying to install and operate CSP-Kerberos. Most software that implements distributed time protocols needs some time to stabilize. This time is not merely to allow the administrator to perform the installation and configuration correctly; most distributed time software requires time to determine the characteristics of each local clock it is expected to synchronize. Sometimes this determination takes several days.
Your CSP-Kerberos installation will proceed more smoothly if you have a solid, trustworthy, distributed time mechanism already in place. For more information on keeping system clocks synchronized, see the section titled “Clock Skew Commands” in this chapter.
Because CSP-Kerberos requires separate administration, the chief administrator may need to choose one or more trusted people to serve as CSP-Kerberos administrators. These people create and modify the CSP-Kerberos principal database residing on the CSP-Kerberos primary server, and they also monitor the log files written by CSP-Kerberos.
Your network probably consists of various types of hardware, running many different versions of software. Check with the vendors of your other hardware and software to determine whether they have implementations of this software available on their platforms. If they do not, and if you want to use CSP-Kerberos on the unsupported platform, you must port MIT's Kerberos version 5 to that platform yourself.
CSP-Kerberos can protect your host from certain types of break-ins, but it is possible to install CSP-Kerberos and still leave your host vulnerable to attack. This guide does not attempt to include an exhaustive list of countermeasures for every possible attack, but it is worth noting some of the larger holes and how to close them.
Silicon Graphics recommends that on a secure host, you disable the standard ftp, login, telnet, shell, and exec services in /etc/services. We also recommend that secure hosts have an empty /etc/hosts.equiv file and that there not be a .rhosts file in root's home directory. You can grant CSP-Kerberos authenticated root access to specific CSP-Kerberos principals by placing those principals in the file .k5login in root's home directory.
This section gives installation procedures for each class of CSP-Kerberos systems:
| Note: A system can be any or all of a client and a server and a KDC. |
Before installing CSP-Kerberos, it is necessary to consider the following issues:
The name of your CSP-Kerberos realm (or the name of each realm, if you need more than one). You can select any realm name you choose, but it is advisable to have this name track your IP domain names for ease of use. See “Planning CSP-Kerberos Realms” for more information.
How you will map your hostnames onto CSP-Kerberos realms. Again, it is advisable to have this mapping match your IP domain names. See “Mapping Hostnames Onto CSP-Kerberos Realms” for more information.
Which ports your KDC and kadmin5 (database access) services will use. The defaults are strongly suggested for compatibility. See “Ports for the KDC and Admin Services” for more information.
How many slave KDCs you need and where they should be located within your network topology. See “Planning CSP-Kerberos KDCs” for more information.
The hostnames of your master and slave KDCs. See “Hostnames for the Master and Slave KDCs” for more information.
How frequently you will propagate the database from the master KDC to the slave KDCs. See “CSP-Kerberos Database Propagation” for more information.
The Key Distribution Centers (KDCs) issue CSP-Kerberos tickets. Each KDC contains a copy of the CSP-Kerberos database. The master KDC contains the master copy of the database, which it propagates to the slave KDCs at regular intervals. All database changes (such as password changes) are made on the master KDC.
Slave KDCs provide CSP-Kerberos ticket-granting services, but not database access. This allows clients to continue to obtain tickets when the master KDC is unavailable.
Silicon Graphics recommends that you install all of your KDCs to be able to function as either the master or one of the slaves. This will enable you to easily switch your master KDC with one of the slaves if necessary. This installation procedure is based on that recommendation. Note that this implies that security considerations are the same for all KDCs. Every slave KDC must be protected as thoroughly as your master KDC, since the same realm-wide information is present on each KDC.
This installation procedure will require you to go back and forth a couple of times between the master KDC and each of the slave KDCs. The first few steps must be done on the master KDC.
Edit the configuration files on the master KDC.
Modify the configuration files, /etc/krb5.conf and /krb5/lib/krb5kdc/kdc.conf to reflect the correct information (such as the hostnames and realm name) for your realm. Silicon Graphics recommends that you keep krb5.conf in /etc. The krb5.conf file may contain a pointer to kdc.conf You must change that pointer if you want to move kdc.conf to another location.
Create the database on the master KDC.
Use the kdb5_create and kdb5_stash commands on the Master KDC to create the CSP-Kerberos database and the optional stash file. The stash file is a local copy of the master key that resides in encrypted form on the KDC's local disk. The stash file is used to authenticate the KDC to itself automatically before starting the kadmind5 and krb5kdc daemons as part of the system's boot sequence. The stash file, like the keytab file, is a potential point of entry for a break-in, and if compromised, would allow unrestricted access to the CSP-Kerberos database. If you choose to install a stash file, it should be readable only by root, and should exist only on the KDC's local disk. The file should not be part of any backup of the system, unless access to the backup data is secured as tightly as access to the master password itself.
If you elect not to create a stash file, you must start krb5kdc and kadmind5 individually from a command line using the -m option, and you must provide the appropriate CSP-Kerberos master key for your KDC at start time. With a stash file, this process can be automated, as shown in the examples below.
The decision to use a stash file or not comes down to convenience vs. better security.
Note: The kdb5_create program prompts you for the master key for the CSP-Kerberos database. This key can be any string. A good key is one that you can remember, but no one else can guess. Examples of bad keys are words that can be found in a dictionary, any common or popular name, especially a famous person (or cartoon character), your user name in any form (for example, forward, backward, repeated twice, and so on), and any of the sample keys that appear in this manual. One example of a key which would be good if it did not appear in this manual is “SGIiys4CK5!”, which represents the sentence “Silicon Graphics Inc. is your source for CSP-Kerberos 5!” (It's the first letter of each word, substituting the numeral “4” for the word “for”, and includes the punctuation mark at the end.) The following is an example of how to create a CSP-Kerberos database and stash file on the master KDC, using the kdb5_create and kdb5_stash commands. Replace YOURSITE.COM with the name of your CSP-Kerberos realm.
/krb5/sbin/kdb5_create Initializing database '/krb5/lib/krb5kdc/principal' for realm 'YOURSITE.COM', master key name 'K/[email protected]' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the master password> Re-enter KDC database master key to verify: <Type it again>
This creates three files in the directory specified in your kdc.conf file (usually /krb5/lib/krb5kdc, where the kdc.conf file itself resides): principal.dir, principal.pag, and principal.ok.
Next, create the stash file, .k5<Realm_name>. (The default directory is /krb5/lib/krb5kdc and <Realm_name> is replaced with the actual name of the CSP-Kerberos realm that the stash file represents.) The following example shows the usage:
/krb5/sbin/kdb5_stash Enter KDC database master key: <Type the same key again>
Add users to your database
Add users to your CSP-Kerberos principals database using the kadmin5 utility. A sample usage is shown below:
kadmin5: ank zursch Enter password: <Enter a password for this user> Re-enter password for verification: <Enter it again> kadmin5: q
The command ank within the utility stands for Add New Key. Users entered in the database may change their passwords (and should be encouraged to do so) with the /krb5/bin/kpasswd command.
Add a principal entry to your CSP-Kerberos principals database for the kadmind5 daemon. A sample usage is shown below:
kadmin5: ank kadmind5 Enter password: <Enter a password for this utility> Re-enter password for verification: <Enter it again> kadmin5: q
Start the CSP-Kerberos Daemons on the Master KDC
At this point, you are ready to start the CSP-Kerberos daemons on the Master KDC. To do so, type the commands:
/krb5/sbin/krb5kdc /krb5/sbin/kadmind5
Each daemon will fork and run in the background. Assuming you want these daemons to start up automatically at boot time, you can add them to the KDC's /etc/rc or /etc/inittab file. You need to have a stash file in order to do this.
You are now ready to start configuring the slave KDCs. Slave CSP-Kerberos KDCs allow clients to be able to get CSP-Kerberos tickets even when the master KDC is not available. Users will not be able to change their passwords — changes can only be made to the database on the Master KDC; however, users will be able to authenticate to servers, which is critically important in a distributed client-server environment. The current implementation of the client code does not provide load sharing in that the order of servers contacted is the same as those listed in the krb5.conf file.
In order to propagate the CSP-Kerberos database from the master KDC to the slaves, the kprop and kpropd client/server programs are used. Periodically, you should dump the CSP-Kerberos database out into an ASCII format, using the kdb5_edit program. Then run kprop to propagate the dumped database file to each slave server. This can be done conveniently with a cron(1) job.
On the slave KDC, the kpropd program is invoked through the inetd server. After kprop and kpropd have mutually authenticated with one another, and kpropd is satisfied with the identity of the master KDC, then the dumped ASCII database is transferred to the slave KDC in an encrypted fashion. After the database is transferred, kpropd will then run kdb5_edit with the appropriate arguments in order to undump the database into a usable form by the KDC slave.
To limit the possibility that your CSP-Kerberos database could be compromised, Silicon Graphics recommends that each KDC be a dedicated host, with limited access. If your KDC is also a server, or even just a client system, someone who obtained root access through a security hole in any of those areas could gain access to the CSP-Kerberos database.
Follow these steps to successfully propagate your Master KDC to the slave KDCs:
Each KDC needs a host principal in the master CSP-Kerberos KDC database. For example, if your master KDC is called zork.yoursite.com, and you have two slaves named zork1.yoursite.com and zork2.yoursite.com, you would use the kadmin5 command as shown to add the following principals to the KDC:
kadmin5:ark host/zork.yoursite.com kadmin5:ark host/zork1.yoursite.com kadmin5:ark host/zork2.yoursite.com
Extract the host v5srvtab file for each slave KDC. You must have a keytab on the slave server in order to decrypt tickets during the propagation process. Common sense security rules apply to copying keytab files over the network. You should encrypt the keytab files before any transfer. To extract the v5srvtab files, use the following commands:
kadmin5:xst host kadmin5:xst zork1.yoursite.com host kadmin5:xst zork2.yoursite.com host
Next, copy the extracted keytab files to the /etc directories on their respective hosts:
rcp zork1.yoursite.com-new-srvtab zork1:/etc/v5srvtab rcp zork2.yoursite.com-new-srvtab zork2:/etc/v5srvtab
You must have an ACL file for kpropd. This ACL file must be named /krb5/lib/krb5kdc/kpropd.acl. The ACL file must contain the host principals for each of the KDCs. And it must exist on both the master KDC and all slave KDCs. Continuing the example case, this ACL file would read as follows:
host/[email protected] host/zork1[email protected] host/[email protected]
The inetd.conf file on each involved system must contain this entry:
krb5_prop stream tcp nowait root /krb5/sbin/kpropd kpropd
and of course you must restart inetd with the command:
/etc/killall -HUP inetd
The /etc/services file on each involved system must contain this entry:
krb5_prop 754/tcp # CSP-Kerberos slave propagation
Create the database file to be propagated with kdb5_edit:
kdb5_edit: ddb /krb5/lib/krb5kdc/slave_datatrans kdb5_edit: exit
Propagate the file to each slave KDC. It is usually convenient to write a shell script to perform this task and to register the script as a cron job:
kprop -f /krb5/lib/krb5kdc/slave_datatrans zork1.yoursite.com Database propagation to zork1.yoursite.com: SUCCEEDED kprop -f /krb5/lib/krb5kdc/slave_datatrans zork2.yoursite.com Database propagation to zork2.yoursite.com: SUCCEEDED
On each slave KDC, load the new database as shown:
kdb5_edit: lddb /krb5/lib/krb5kdc/from_master principal.dir kdb5_edit: exit
On each slave KDC, create stash files and then start the krb5kdc daemon as shown:
/krb5/sbin/kdb5_stash Enter KDC database master key: <Type the master key> /krb5/sbin/krb5kdc
A server is a host that provides one or more services over the network. Servers can be “secure” or “insecure.” A “secure” host is set up to require authentication from every client connecting to it. An “insecure” host will still provide CSP-Kerberos authentication, but will also allow unauthenticated clients to connect.
If you have CSP-Kerberos installed on all of your client systems, Silicon Graphics recommends that you make your hosts secure, to take advantage of the security that CSP-Kerberos authentication affords. However, if you have some clients that do not have CSP-Kerberos installed, you can run an insecure server, and still take advantage of CSP-Kerberos's authentication capability.
Just as CSP-Kerberos provided its own CSP-Kerberos-enhanced versions of client network programs, CSP-Kerberos also provides CSP-Kerberos-enhanced versions of server network daemons. These are ftpd, klogind, kshd, and telnetd These programs are installed in the directory /krb5/sbin. You may want to add this directory to root's path.
For a secure server, Perform these steps:
Make the following changes to /etc/inetd.conf on your new server:
Find and comment out any lines for the services ftp, telnet, shell, and exec.
Add the following lines to /etc/inetd.conf:
klogin stream tcp nowait root /krb5/sbin/klogind klogind -k -c eklogin stream tcp nowait root /krb5/sbin/klogind klogind -k -c -e kshell stream tcp nowait root /krb5/sbin/kshd kshd -k -c -A ftp stream tcp nowait root /krb5/sbin/ftpd ftpd -a telnet stream tcp nowait root /krb5/sbin/telnetd telnetd -a valid
See the various reference pages for the above listed programs for information on their options and syntax.
Add a principal entry for your new server host in the KDC.
If you have any custom CSP-Kerberized applications being served, a principal entry must be created on the KDC for that application.
Extract a keytab (v5srvtab) file for your server from the KDC.
Place the v5srvtab file in the /etc directory of your server.
Give the command:
killall -hup inetd
on your server to reset inetd.
For an insecure server, perform the following steps:
Make the following changes instead to /etc/inetd.conf:
Find and comment out any lines for the services ftp and telnet.
Add the following lines to /etc/inetd.conf:
klogin stream tcp nowait root /krb5/sbin/klogind klogind -k -c eklogin stream tcp nowait root /krb5/sbin/klogind klogind -k -c -e kshell stream tcp nowait root /krb5/sbin/kshd kshd -k -c -A ftp stream tcp nowait root /krb5/sbin/ftpd ftpd telnet stream tcp nowait root /krb5/sbin/telnetd telnetd -a none
See the various reference pages for the above listed programs for information on their options and syntax.
Add a principal entry for your new server in the KDC.
Extract a keytab (v5srvtab) file for your server from the KDC.
Place the v5srvtab file in the /etc directory of your server.
Give the command:
killall -hup inetd
on your server to reset inetd.
Client system installation is much more straightforward than installation of the KDCs.
At the most basic level, you will install the csp-kerberos.sw.client software package from your distribution and register your users as principals in the KDC database.
The CSP-Kerberized client programs are rlogin, telnet, ftp, rcp, rsh and ksu. All of these programs are in the directories /krb5/bin and /krb5/sbin.
You will probably want to have your users put /krb5/bin and /krb5/sbin ahead of /bin and /usr/bin in their paths, so they will by default get the CSP-Kerberos versions of rlogin, telnet, ftp, rcp, and rsh. If a user invokes the kerberized version of a program and attempts to access a system not using CSP-Kerberos, the kerberized version of the command will time out and then automatically use the non-kerberized version of the same program to access the remote host.
You will also need to educate your users to use the ticket management programs kinit, krb524init, klist, kpasswd and kdestroy, and to use the CSP-Kerberos programs pfrom, ksu, and kpasswd in place of their non-CSP-Kerberos counterparts from, su and passwd.
Each system running CSP-Kerberos must have a /etc/krb5.conf and an /krb5/lib/krb5kdc/kdc.conf file. All files have sample copies provided in your CSP-Kerberos distribution that are installed in the /krb5 directory.
Here is a sample kdc.conf file:
[kdcdefaults]
kdc_ports = 750,88
[realms]
YOURSITE.COM = {
profile = /etc/krb5.conf
database_name = /krb5/lib/krb5kdc/principal
key_stash_file = /krb5/lib/krb5kdc/.k5.YOURSITE.COM
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
supported_enctypes = des-cbc-crc:normal des:normal des:v4
des:norealm des:onlyrealm des:afs3
}
|
Also, the following lines are added to your /etc/services file:
# CSP-Kerberos (Commercial Security Pak Kerberos) services kerberos 88/udp kdc # CSP-Kerberos authentication--udp kerberos 88/tcp kdc # CSP-Kerberos authentication--tcp kerberos-sec 750/udp # CSP-Kerberos authentication--udp kerberos-sec 750/tcp # CSP-Kerberos authentication--tcp kerberos_master 751/udp # CSP-Kerberos authentication kerberos_master 751/tcp # CSP-Kerberos authentication kerberos-adm 749/tcp # CSP-Kerberos 5 admin/changepw kerberos-adm 749/udp # CSP-Kerberos 5 admin/changepw kpop 1109/tcp # Pop with CSP-Kerberos kshell 544/tcp cmd # and remote shell klogin 543/tcp # CSP-Kerberos authenticated rlogin eklogin 2105/tcp # CSP-Kerberos encrypted rlogin krb5_prop 754/tcp # CSP-Kerberos slave propagation krb524 4444/tcp # CSP-Kerberos 5 to 4 ticket xlator #CSP-Kerberos test sample 906/tcp # CSP-Kerberos sample app server |
If your master KDC or any of your slave KDCs is running Kerberos V4, (or if you will be authenticating to any Kerberos V4 KDCs in another realm) you will need to switch the port number for kerberos to 750 and create a kerberos-sec service (tcp and udp) on port 88, so the Kerberos V4 KDC(s) will continue to work properly. The file /etc/services.N can replace your /etc/services file directly in this case.
The following sections provide configuration advice for all types of systems in your CSP-Kerberos realm.
Usually the CSP-Kerberos configuration file is named /etc/krb5.conf in IRIX applications. This file contains information about the local CSP-Kerberos configuration. A sample /etc/krb5.conf file follows:
# Sample /etc/krb.conf file YOURSITE.COM yoursite.com krb_kdc_1 yoursite.com krb_kdc_2 yoursite.com krb_kdc_1 admin server |
Line 1 specifies the name of the local realm. In the example file, this is simply YOURSITE.COM. (You are free to name your realm whatever you choose; however, the realm name in the /etc/krb5.conf file must match the realm name used to create the CSP-Kerberos database on the CSP-Kerberos KDC; realm names are case sensitive.) Lines 2 and 3 list the host names for two CSP-Kerberos KDCS, krb_kdc_1 and krb_kdc_2. These are the KDCs that the CSP-Kerberos software asks for tickets. The software searches the /etc/krb5.conf file from the top and tries each listed KDC until it obtains a response. (This implies that load balancing could be achieved by having some hosts list krb_kdc_2 before krb_kdc_1 in their /etc/krb5.conf files.)
The last line indicates the location at which the CSP-Kerberos administrative server process is running. It is recommended that only one administrative server process be configured, because no mechanism is in place to propagate changes to the CSP-Kerberos principal database from a slave back to the primary server. For example, if there were multiple administrative server processes running, and a password change were made on a server, the new password would not be propagated back to the master.
The IRIX operating system supports the following kerberized servers: telnetd(8), ftpd(8), klogind(8), and rshd(8). The telnetd server provides enhancements to the existing protocols to support CSP-Kerberos authenticated sessions. If the client applications connecting to these servers support CSP-Kerberos, and if they choose to use CSP-Kerberos, they are supported. Non-kerberized client applications also are supported, however, and their functionality has not been changed.
The klogind server supports kerberized rlogind connections. The new klogind daemon is the same as the non-kerberized version, except that it performs CSP-Kerberos authentication on the client before executing /bin/login with the -f (force login) option. The klogind daemon listens on port 543. If the client klogin wants to establish a connection that is encrypted in addition to being authenticated by CSP-Kerberos, the client can try to connect to port 2105 on your system, at which eklogind will be listening. This server uses the session key, established as part of the CSP-Kerberos authentication, to encrypt and decrypt the data stream between the host and your system. The eklogind daemon is actually the same binary file as klogind, but it is initiated with different options from inetd(8).
The new rshd server supports kerberized rshd connections. This server is analogous to rshd, except that it performs CSP-Kerberos authentication on the client. The rshd daemon listens for connections on port 544. The rshd daemon supports kerberized versions of both rsh(1) and rcp(1).
The ftpd server supports additional comments that allow a kerberized ftp(1) to send authentication commands, protect commands in the control channel, and transfer files on the data channel using cryptographic checksum, SAFE, or encrypted file transfer PRIVATE, as well as the current clear text transfers.
The network services configuration file, /etc/services, should be modified to support running CSP-Kerberos utilities or kerberized clients and servers on your system. Specifically, the following lines should be added:
# /etc/services file klogin 543/tcp # kerberized rlogin kshell 544/tcp # kerberized rshd kerberos 750/udp # CSP-Kerberos server kerberos_master 751/tcp # CSP-Kerberos administrator eklogin 2105/tcp # CSP-Kerberos encrypted rlogin |
| Note: Support for data stream encryption in kerberized applications is not available outside of the United States and Canada; therefore, the eklogin line should not be added at sites outside of the United States and Canada. |
You can advertise CSP-Kerberos network services over NIS if you are running this optional software on your network domain. Consult the NIS documentation for information on advertising network services in your NIS domain.
In addition, the /etc/inetd.conf file must be modified to support the invocation of kerberized services. The following lines must be added to /etc/inetd.conf to support kerberized services on your system:
# /etc/inetd.conf file kshell stream tcp nowait root /etc/kshd kshd klogin stream tcp nowait root /etc/klogind klogind eklogin stream tcp nowait root /etc/klogind eklogind |
The first line (kshell) enables the kerberized krshd (8) server. The second line (klogin(8)) line enables the kerberized klogind(8) server. The third line (eklogin) enables the kerberized and encrypted klogind server. Obviously, these lines should not be added if your site does not run these kerberized servers on your Silicon Graphics system.
You must add the /.k5login file at sites that use the ksu(1) client application. This file contains a list of users who are allowed to become superuser. A sample /.k5login file follows:
[email protected] [email protected] |
Each line contains username.root@ LOCALREALM; username is the user name of the process. The ksu program tries to fetch a ticket-granting ticket by using username. root@ LOCALREALM.
The /etc/krb.conf file must have permissions set to 600 and be owned by root.
You can configure the krb5.conf file to allow users accessing your CSP-Kerberos services through the telnet program to obtain tickets without the use of the kinit command. Edit your /etc/krb5.conf file and ensure that the krb5_get_tickets entry is set to 1 as shown here:
krb5_get_tickets = 1 |
If this value is set to 1, the user is prompted for his or her CSP-Kerberos password before the telnet connection is made. If this value is set to 0, the user is prompted for his or her IRIX password, and then must execute kinit to receive tickets.
The /etc/krb5.conf file should have permissions set to 644 and be owned by root.
To add a new kerberized server application to your system, you must add an entry to the /etc/inetd.conf file if the server is to be started by inetd. You can access the /etc/inetd.conf file through the menu system. You can also start the server by using your local netstart(8) script, or you can start the server manually.
Consider the following example for adding an entry to the CSP-Kerberos principal database: Assume that you are the CSP-Kerberos administrator. You are adding a server that requires the use of a ticket called mathsrv and your system hostname is localsys. Assume that no other server on your host requires a ticket named mathsrv. You must perform some further steps to enable this server to run.
You must go to the primary CSP-Kerberos server system and use kdb_edit to add a new entry to the principal database. The name of the principal should be mathsrv, and its instance should be localsys. Run the kadmin5 program to obtain a random password for the principal.
| Note: The CSP-Kerberos administrator cannot select this password. It must be a random password generated by the kadmin5 program, which allows the administrator to edit the principal database. Because this password will never need to be typed in by any person, its content is unimportant. |
After you have entered mathsrv.localsys into the CSP-Kerberos principal database, extract a new v5srvtab file from the database with the kadmin5 command and move that file onto the localsys host. The MIT distribution of Kerberos version 4 provides a program call ext_srvtab to perform this task. When given the name localsys, the ext_srvtab program scans the database for all services registered with instances of localsys. Then it writes the names and passwords for these services to a file called new-localsys-srvtab. This file must be treated with caution, since it contains passwords to all registered services on your system.
Once the initial KDC database is created and loaded and the keytab file with an entry for kadmind5 is extracted, you no longer need to use kdb5_edit to add new entries in the principals database. You can use the kadmin5 command thereafter.
Transfer this file to localsys in whatever secure manner is appropriate. For example, encrypted and transferred using ftp, put onto a tape, and so on. Name this file /etc/v5srvtab on localsys, set its permissions to 600, and ensure that it is owned by root. Double check the permissions to avoid a security breach.
This distribution provides the following CSP-Kerberos client programs:
| rcp(1) | Copies files between systems that use CSP-Kerberos authentication when they connect to the remote host. | ||
| rlogin(1) | Connects a terminal on the current local host system to a remote host that uses CSP-Kerberos authentication to determine authorization. Users who want to call the CSP-Kerberos authenticated remote login feature can use this command. | ||
| rsh(1) | Uses CSP-Kerberos authentication to connect to the specified host, and then executes the specified command. | ||
| ksu(1) | Uses CSP-Kerberos authentication to allow superuse of another account. | ||
| telnet(1B) | Uses TELNET protocol to communicate with a remote host. Users who want to use CSP-Kerberos authenticated telnet can either use the telnet command with the -a option and hostname variable, or use the telnet command followed by passing the open command with the -a option and the hostname variable to telnet. Users who want to run encrypted and CSP-Kerberos authenticated telnet(1B) sessions should escape into telnet and enter the following commands:
If you do not set any of these authentication or encryption options, telnet will establish a unauthenticated session for the user. Before running CSP-Kerberos authenticated telnet, a user must acquire a service-granting ticket from CSP-Kerberos by running kinit(1) on your system. Unless a user uses an encrypted session when logging into your system, the CSP-Kerberos password will traverse the network from the local host to your system without being encrypted. Use klogin -x or the encrypted option of telnet to avoid this problem. | ||
| ftp(1B) | Uses the FTP protocol to authenticate clients to servers with the AUTH and ADAT commands. Allows transfer of files in clear text, cryptographic checksum, or encrypted form. All commands sent over the control channel are protected by base 64 encoding with optional encryption if the private command is selected. (The private command is not available outside of the United States and Canada.) |
Users can also use the following commands:
kinit (to obtain a ticket-granting-ticket).
klist (to list CSP-Kerberos tickets).
kdestroy (to destroy CSP-Kerberos tickets)
kpasswd (to change CSP-Kerberos passwords).
Users should be encouraged to include the kdestroy command in their .logout files; this command helps ensure that their ticket files are not available to unauthorized users after they have logged off.
If the servers were installed correctly, the only action you must take to add CSP-Kerberos clients is to move the program to the directory in which you want the client to reside. (If you want to use library routines such as getservbyname (see getserv(3)) to obtain the remote port number, you may need to add entries to the /etc/services file, but these tasks are not specifically related to CSP-Kerberos.)
The procedure for adding new CSP-Kerberos users is similar to that for adding new CSP-Kerberos servers. Both involve editing the principal database on the primary CSP-Kerberos server. Unlike the server, the user needs a password that can be remembered. Thus, when the kdb_edit (or equivalent) program prompts the CSP-Kerberos administrator for a password, the CSP-Kerberos administrator must type in something that the user can remember and type in again. The CSP-Kerberos administrator can have the user present, to type in his or her own password, or the CSP-Kerberos administrator can choose an initial password for the user and then have the user change it by using the kpasswd command. These are the same procedures used when system administrators create new accounts for users.
If you need offsite users to be able to get CSP-Kerberos tickets in your realm, they must be able to get to your KDC. This requires either that you have a slave KDC outside your firewall, or you configure your firewall to allow UDP requests into to at least one of your KDCs, on whichever port the KDC is running. (The default is port 88; other ports may be specified in the KDC's /krb5/lib/krb5kdc/kdc.conf file.) Similarly, if you need off-site users to be able to change their passwords in your realm, they must be able to get to your CSP-Kerberos admin server. The default port for the admin server is 749.
If your onsite users inside your firewall need to get to KDCs in other realms, you must configure your firewall to allow outgoing TCP and UDP requests to port 88. Additionally, if they will need to get to any Kerberos V4 KDCs, you may also need to allow TCP and UDP requests to port 750. If your onsite users inside your firewall need to get to CSP-Kerberos admin servers in other realms, you will also need to allow outgoing TCP and UDP requests to port 749.
If any of your KDCs are outside your firewall, you must allow kprop requests to get through to the remote KDC. The kprop program uses the krb5_prop service on port 754 (tcp).
If you need your offsite users to have access to systems inside your firewall, you need to allow TCP connections from their offsite hosts on the appropriate ports for the programs they will be using. The following lines from /etc/services show the default port numbers for the CSP-Kerberos programs:
# CSP-Kerberos (Commercial Security Pak Kerberos) services kerberos 88/udp kdc # CSP-Kerberos authentication--udp kerberos 88/tcp kdc # CSP-Kerberos authentication--tcp kerberos-sec 750/udp # CSP-Kerberos authentication--udp kerberos-sec 750/tcp # CSP-Kerberos authentication--tcp kerberos_master 751/udp # CSP-Kerberos authentication kerberos_master 751/tcp # CSP-Kerberos authentication kerberos-adm 749/tcp # CSP-Kerberos 5 admin/changepw kerberos-adm 749/udp # CSP-Kerberos 5 admin/changepw kpop 1109/tcp # Pop with CSP-Kerberos kshell 544/tcp cmd # and remote shell klogin 543/tcp # CSP-Kerberos authenticated rlogin eklogin 2105/tcp # CSP-Kerberos encrypted rlogin krb5_prop 754/tcp # CSP-Kerberos slave propagation krb524 4444/tcp # CSP-Kerberos 5 to 4 ticket xlator #CSP-Kerberos test sample 906/tcp # CSP-Kerberos sample app server |
By default, CSP-Kerberos telnet and ftp use the same ports as the standard telnet and ftp programs, so if you already allow such connections through your firewall, the CSP-Kerberos versions will get through as well. If you do not already allow such connections through your firewall, but need your users to be able to use CSP-Kerberos connections, you can either allow ftp and telnet connections on the standard ports, or switch these programs to non-default port numbers and allow connections on those ports to get through.
CSP-Kerberos klogin uses the klogin service, which by default uses port 543. Encrypted CSP-Kerberos klogin -x uses the eklogin service, which by default uses port 2105.
CSP-Kerberos rsh uses the kshell service, which by default uses port 544. However, the server must be able to make a TCP connection from the kshell port to an arbitrary port on the client, so if your users are to be able to use rsh from outside your firewall, the server they connect to must be able to send outgoing packets to arbitrary port numbers. Similarly, if your users need to run rsh from inside your firewall to hosts outside your firewall, the outside server needs to be able to connect to an arbitrary port on the system inside your firewall. Because CSP-Kerberos rcp uses rsh, the same issues apply. If you need to use rsh (or rcp) through your firewall and are concerned with the security implications of allowing connections to arbitrary ports, Silicon Graphics suggests that you have rules that specifically name these applications and, if possible, list the allowed hosts.
A reasonably good cookbook for configuring firewalls is available by FTP from ftp.livingston.com, in the location /pub/firewall/firewall-1.1.ps.Z. The book UNIX System Security, by David Curry, is also a good starting point.
The default ports used by CSP-Kerberos are port 88 for the KDC and port 749 for the admin server. You can, however, choose to run on other ports, as long as they are specified in each host's /etc/services and krb5.conf files, and the /krb5/lib/krb5kdc/kdc.conf file on each KDC. Because the kadmin5 port was recently assigned, Silicon Graphics recommends that you specify it explicitly in your krb5.conf and kdc.conf files.
If you are configuring Silicon Graphics CSP-Kerberos into an existing installation using a Distributed Computing Environment KDC, you must make the following changes to your configuration for compatibility.
You must install the software package csp-kerberos.sw.server-dce-interop from your CSP-Kerberos software distribution on any servers that will be interoperating with a DCE installation.
The keytab file in Silicon Graphics CSP-Kerberos is /etc/v5srvtab. However in DCE this file is found in /krb5/v5srvtab. Create a link between these two locations with this command:
ln /etc/v5srvtab /krb5/v5srvtab
The network service name must be aliased in the /etc/services file. The CSP-Kerberos service is named kerberos in the Silicon Graphics implementation. DCE implementations expect to find the service called kerberos5 on port 88.
Thus, you must create an alias for the kerberos entry to also respond to the name kerberos5:
Here is the standard DCE entry in /etc/services:
kerberos5 88/udp kdc # CSP-Kerberos 5/ DCE KDC
The Silicon Graphics implementation entry is as follows:
kerberos 88/udp kdc # CSP-Kerberos authentication--udp
Add this alias entry to the /etc/services file to allow interoperation:
kerberos 88/udp kerberos5 kdc # CSP-Kerberos 5 / DCE KDC
You must make sure of the following settings in the /etc/krb5.conf file:
kdc_req_checksum_type = 2 ccache_type = 1
Setting the kdc_req_checksum_type entry to 2 forces the software to use CKSUMTYPE_RSA_MD4 for checksum service. This is the standard for DCE 1.1 and earlier compatibility. The Silicon Graphics implementation default is CKSUMTYPE_RSA_MD5.
Setting the ccache_type entry to 2 allows for current DCE compatibility. Set this value to 1 for DCE 1.0.3a and earlier systems and set it to 2 for DCE 1.1 systems.
An example /etc/krb5.conf file looks similar to this:
[libdefaults] default_realm = laughter.rain.com kdc_req_checksum_type = 2 ccache_type = 1 [realms] laughter.rain.com = { kdc = laughter admin_server = laughter.rain.com default_domain = rain.com } [domain_realm] .rain.com = laughter.rain.com [login] krb4_get_tickets = 0 krb4_convert = 0 [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.logDCE Kerberos uses a specific form of credential that must be converted to be compatible with the Silicon Graphics implementation of CSP-Kerberos. To allow klogind to convert a Silicon Graphics ticket to a DCE credential, the program /krb5/sbin/k52dce is included in your distribution. For complete information about this program, see the k52dce reference page.
Your CSP-Kerberos database contains all of your realm's CSP-Kerberos users, called “principals,” their passwords, and other administrative information about each principal. For the most part, you use the kdb5 utilities to manipulate the CSP-Kerberos database as a whole, and the kadmin5 program to make changes to the entries in the database. (One notable exception is that users use the kpasswd program to change their own passwords.) The kadmin5 program has its own command-line interface, to which you type the database administration commands.
The kadmin5 command provides for the maintenance of CSP-Kerberos principals and KADM5 policies. It exists as a CSP-Kerberos client, kadmin5, using CSP-Kerberos authentication to operate securely from anywhere on the network.
The kdb5 tools provide a means to create, delete, edit, load, or dump a CSP-Kerberos database. They also include a command to stash a copy of the master database key in a file on a KDC, so that the KDC can authenticate itself to the kadmind5 and krb5kdc daemons at boot time.
You can invoke kadmin5 with any of the following options:
| -r REALM | Use REALM as the default CSP-Kerberos realm for the database. | |
| -k keytab | Use the specified keytab file to decrypt the KDC response instead of prompting for a password on the TTY. In this case, the principal is host/hostname. | |
| -p principal | Use the CSP-Kerberos principal principal to authenticate to CSP-Kerberos. If this option is not given, kadmin5 will append admin to either the primary principal name, the environment variable USER, or to the username obtained from getpwuid, in order of preference. | |
| -c credentials cache |
| |
| -l Time | Use Time as the lifetime of an administrative ticket. | |
| -d | Specifies that the credentials cache is to be deleted after use. | |
| -s | Specifies that the credentials cache is to be saved after use. | |
| -m | Specifies that multiple operations will be permitted for only one entry of the administrative principal's password. |
You must have an ACL file in /krb5/lib/krb5kdc in order to run kadmin5. The ACL file specifies access control rules for CSP-Kerberos administrators. Note that this ACL file is in no way related to the ACL services provided in the IRIX portion of the Commercial Security Pak software distribution.
The ACL file controls which principals can or cannot perform which administrative functions on which principals. This file can contain comment lines, null lines or lines which contain ACL entries. Comment lines start with the hashmark sign ( # ) and continue until the end of the line. Lines containing ACL entries have the format:
principal operation-mask [operation-target] |
Ordering is important. The first matching entry is the one which controls access for a particular principal on a particular host.
Here is a typical ACL file entry:
root/[email protected] admci |
The ACL file can either be specified on the command line for kadmind5 as follows:
kadmind5 -a /krb5/lib/krb5kdc/<custom.acl> |
or you can use the default /krb5/lib/krb5kdc/krb5_adm.acl.
The ACL file can be created with any text editor, it is a plain ASCII text file.
For complete information on the syntax for ACL file entries, see the kadmind5(8) reference page.
Many of the kadmin5 commands take a duration or time as an argument. The date can appear in a wide variety of formats, such as those shown below:
"15 minutes" "7 days" "1 month" "2 hours" "400000 seconds" "next year" "this Monday" "next Monday" yesterday tomorrow now "second Monday" fortnight "3/31/92 10:00:07 PST" "January 23, 1987 10:05pm" "22:00 GMT" |
Note that if the date specification contains spaces, you must enclose it in double quotes. Note also that you cannot use a number without a unit. (For example, “60 seconds” is correct, but “60” is incorrect.) All keywords are case insensitive. The following is a list of all of the allowable keywords:
| Months | january, jan, february, feb, march, mar, april, apr, may, june, jun, july, jul, august, aug, september, sept, sep, october, oct, november, nov, december, dec | |
| Days | sunday, sun, monday, mon, tuesday, tues, tue, wednesday, wednes, wed, thursday, thurs, thur, thu, friday, fri, saturday, sat | |
| Units | year, month, fortnight, week, day, hour, minute, min, second, sec | |
| Relative | tomorrow, yesterday, today, now, last, this, next, first, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, eleventh, twelfth, ago | |
| Time Zones | The kadmin5 command recognizes abbreviations for most of the world's time zones. A complete listing appears in Appendix A of this guide. | |
| 12-Hour Time Delimiters |
|
Each entry in the CSP-Kerberos database contains a CSP-Kerberos principal (a user) and the attributes and policies associated with that principal.
To retrieve a listing of the attributes or policies associated with a principal, use the kadmin5 show_principal command, which requires the “inquire” administrative privilege. The syntax is
show_principal principal |
The show_principal command has the alias show.
For example, suppose you wanted to view the attributes of the principals zursch/[email protected] and [email protected]. You would type the following
kadmin5 kadmin5: show zursch/root Principal: zursch/[email protected] Key version: 3 Maximum life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Master key version: 1 Expires: Mon Jan 18 22:14:07 EDT 2038 Password expires: Mon Sep 19 14:40:00 EDT 1996 Password last changed: Mon Jan 31 02:06:40 EDT 1996 Last modified: by root/[email protected] on Wed Jul 13 18:27:08 EDT 1996 Attributes: DISALLOW_FORWARDABLE, DISALLOW_PROXIABLE, REQUIRES_HW_AUTH Salt type: DEFAULT |
To generate a listing of principals, use the kadmin5 list_db command, which requires the “list” privilege. The syntax is:
list_db expression |
where expression is a shell-style “glob” regular expression that can contain the characters *, ?, [, and ]. All policy names matching the expression are displayed. The list_db command has the alias ldb. For example:
kadmin5: ldb test* [email protected] [email protected] [email protected] [email protected] |
If no expression is provided, all principals are printed.
To add a principal to the database, use the kadmin5 add_new_key command. The syntax is
add_new_key [options] principal |
To modify attributes of a principal, use the kadmin5 modify_entry command. The syntax is
modify_entry [options] principal
The add_new_key command has the alias ank. The modify_entry command has the alias modent.
The add_new_key and modify_entry commands take the following switches
| -expiration date |
| |
| -pwexpiration date |
| |
| -maxlife maxlife |
| |
| -maxrenewlife maxlife |
|
If you simply want to use the default values, simply use the following process:
kadmin5: ank zursch WARNING: no policy specified for "[email protected]"; defaulting to no policy. Enter password for principal zursch <Enter Password> Re-enter password for principal zursch <Re-Enter Password> Principal "zursch" created. |
If, on the other hand, you want to set up an account that expires on January 1, 2000, you would type the following.
kadmin5: ank jennifer -expiration "1/1/2000 12:01am EST" Enter password for principal jennifer: <Enter Password> Re-enter password for principal jennifer: <Re-Enter Password> Principal "[email protected]" created. |
If you need cross-realm authentication, add principals for the other realm's TGT to each realm. For example, if you need to do cross-realm authentication between the realms YOURSITE.COM and THEIRSITE.COM, add the principals krbtgt/[email protected] and krbtgt/[email protected] to both databases. Be sure the passwords and the key version numbers are the same in both databases.
To delete a principal, use the kadmin5 delete_principal command, which requires the “delete” administrative privilege. The syntax is
delete_entry principal |
The delete_entry command has the alias delent. For example:
delent jennifer Are you sure you want to delete the principal [email protected]? (yes/no): yes Principal "[email protected]" deleted. |
To rename a principal, use the kadmin5 rename_entry command. The syntax is
rename_entry old_principal new_principal |
The rename_entry command has the alias renent. For example:
renent test test0 Are you sure you want to rename the principal [email protected] to [email protected]"? (yes/no): yes Principal "te[email protected]" renamed to "test0YOURSITE.COM". |
The user's password is the fundamental level of security within CSP-Kerberos. All the standard rules regarding the use and selection of good passwords should be enforced under CSP-Kerberos. See the IRIX Admin: Backup, Security, and Accounting guide for more information on good password selection rules. Remember, though, that CSP-Kerberos passwords are in no way related to your system password used on IRIX, except that all passwords on any system should be well-chosen.
To change a principal's password, use the change_pwd_key command within kadmin5. The syntax is
change_pwd_key [options] principal |
The change_pwd_key command has the alias cpw. For example:
cpw zursch Enter password for principal [email protected]: <Enter Password> Re-enter password for principal [email protected] <Re-Enter Password> Password for [email protected] changed. |
Note that change_pwd_key will not let you change the password to one that is in the principal's password history.
As with any file, it is possible that your CSP-Kerberos database could become corrupted. If this happens on one of the slave KDCs, you might never notice, since the next automatic propagation of the database would install a fresh copy. However, if it happens to the master KDC, the corrupted database would be propagated to all of the slaves during the next propagation. For this reason, Silicon Graphics recommends that you back up your CSP-Kerberos database regularly. Because the master KDC is continuously dumping the database to a file in order to propagate it to the slave KDCs, it is a simple matter to have a cron job periodically copy the dump file to a secure system elsewhere on your network. (Of course, it is important to make the host where these backups are stored as secure as your KDCs, and to encrypt its transmission across your network.) Then if your database becomes corrupted, you can load the most recent dump onto the master KDC.
To dump a CSP-Kerberos database into a file, use the kdb5_edit dump_db command on one of the KDCs. The syntax is
kdb5_edit dump_db [filename [principals...]] |
For example:
kdb5_edit dump_db dumpfile kadmin5/[email protected] krbtgt/[email protected] kadmin5/hist[email protected] K/[email protected] kadmin5/[email protected] |
If you specify which principals to dump, you must use the full principal, as in the following example:
kdb5_edit dump -verbose dumpfile K/[email protected] kadmin5/a[email protected] kadmin5/[email protected] K/[email protected] |
Otherwise, the principals will not match those in the database and will not be dumped:
kdb5_edit dump dumpfile K/M kadmin5/admin |
If you do not specify a dump file, kdb5_edit will dump the database to the standard output.
When you back up a secure host, you should exclude the host's keytab file from the backup. If someone obtained a copy of the keytab from a backup, that person could make any host masquerade as the host whose keytab was compromised. This could be particularly dangerous if the compromised keytab was from one of your KDCs. If the system has a disk crash and the keytab file is lost, it is easy to generate another keytab file. If you are unable to exclude particular files from backups, you should ensure that the backups are kept as secure as the host's root password.
If you need to create a new CSP-Kerberos database, use the kdb5_create command. The syntax is
kdb5_create |
For example:
/krb5/sbin/kdb5_create kdb5_create: No such file or directory while setting active database to '/krb5/principal' Initializing database '/krb5/lib/krb5kdc/principal' for realm 'YOURSITE.COM', master key name 'K/[email protected]' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the master key> Re-enter KDC database master key to verify: <Type it again> |
If you need to destroy a CSP-Kerberos database, use the kdb5_destroy command. The syntax is:
kdb5_destroy |
All traces of the database will be removed.
A keytab is a host's copy of its own keylist, which is analogous to a user's password. A server that needs to authenticate itself to the KDC has to have a keytab that contains its own principal and key. Just as it is important for users to protect their passwords, it is equally important for servers to protect their keytabs. You should always store keytab files on local disk, and make them readable only by root, and you should never send a keytab file over a network in the clear. Ideally, you should run the kadmin5 command to extract a keytab on the host on which the keytab is to reside.
All CSP-Kerberos servers need a keytab file, called /etc/v5srvtab. The keytab was called an srvtab in version 4 of Kerberos. The v5srvtab file has not been renamed to reflect the change in terminology (calling it a keytab file.) The keytab file is an encrypted, local, on-disk copy of the host's key. The keytab file, like the stash file, is a potential point of entry for a break in, and if compromised, would allow unrestricted access to its host. The keytab file must be readable only by root, and should exist only on the system's local disk. The file should not be part of any backup of the system, unless access to the backup data is secured as tightly as access to the system's root password itself.
In order to generate a keytab for a host, the host must have a principal in the CSP-Kerberos database. The procedure for adding hosts to the database is described fully in the section of this guide titled “CSP-Kerberos Principal Commands.” The keytab is generated by running kadmin5 and issuing the ktadd command.
For example, to generate a keytab file to allow the host trillium.yoursite.com to authenticate for the services host and sample, the administrator would issue the command (on trillium, within the kadmin5 utility):
ktadd host/trillium.yoursite.com sample/trillium.yoursite.com kadmin: Entry for principal host/[email protected] with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE: /etc/v5srvtab. kadmin: Entry for principal sample/[email protected] with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE: /etc/v5srvtab. kadmin: quit |
If you generate the keytab file on another host, you need to get a copy of the keytab file onto the destination host (trillium, in the example above) without sending it unencrypted over the network. If you have installed the CSP-Kerberos client programs, you can use encrypted rcp.
Keytab files are manipulated with the ktutil utility. This utility is similar in formation to the kadmin5 and kdb5 utilities. The available commands are:
| clear_list, clear | Clear the current keylist. | |
| read_kt, rkt | Read a krb5 keytab into the current keylist. | |
| read_st, rst | Read a krb4 srvtab into the current keylist. | |
| write_kt, wkt | Write the current keylist to a krb5 keytab. | |
| write_st, wst | Write the current keylist to a krb4 srvtab. | |
| delete_entry, delent |
| |
| list, l | List the current keylist. | |
| list_requests, lr, ? |
| |
| quit, exit, q | Exit program. |
Note that keylist files were called srvtab files in Kerberos version 4 and are called keytab files in version 5.
In order to prevent intruders from resetting their system clocks in order to continue to use expired tickets, CSP-Kerberos is set up to reject ticket requests from any host whose clock is not within the specified maximum clock skew of the KDC (as specified in the /krb5/lib/krb5kdc/kdc.conf file). Similarly, hosts are configured to reject responses from any KDC whose clock is not within the specified maximum clock skew of the host (as specified in the krb5.conf file). The default value for maximum clock skew is 300 seconds (five minutes).
Silicon Graphics suggests that you add a line to client systems' /etc/rc files to synchronize the system's clock to your KDC at boot time. On IRIX hosts, assuming you had a KDC called timeserver in your realm, this would be
gettime -s timeserver |
If the host is not likely to be rebooted frequently, you may also want to set up a cron job that adjusts the time regularly.
Several aspects of CSP-Kerberos rely on name service. In order for CSP-Kerberos to provide its high level of security, it is less forgiving of name service problems than some other parts of your network. It is important that your Distributed Name Service (DNS) entries and your hosts have the correct information.
Each host's canonical name must be the fully qualified hostname (including the domain), and each host's IP address must reverse-resolve to the canonical name.
Other than the localhost entry, make all entries in each system's /etc/hosts file in the following form:
IP address fully-qualified hostname aliases |
Here is a sample /etc/hosts file:
# this is a comment 127.0.0.1 localhost [email protected] 127.150.83.5 [email protected] trillium wake-robin |
Finally, each host's keytab file must include a host/key pair for the host's canonical name. You can list the keys in a keytab file by entering the command klist -K. For example:
klist -K Keytab name: /etc/v5srvtab KVNO Principal ---- --------------------------------------- 1 host/[email protected] |
If you use the telnet command to reach the host with a fresh credentials cache (ticket file), and then use the klist command, the host's service principal should be host/[email protected]_NAME
CSP-Kerberos libraries include the following:
All CSP-Kerberos libraries are installed in the /usr/lib directory.
Several things should be noted about the CSP-Kerberos libraries. First, libkadm.a is used to build only kpasswd(1); libkadm.a is not designed to have user interfaces. Second, libknet.a is also used to build some CSP-Kerberos applications; like libkadm.a, it is not designed to be used by user-level applications. Finally, libkrb.a, as it appears in the default distribution, contains only routines that return without performing any encryption function. If CSP-Kerberos is built only from the source code on the default release media, it will not function properly.
The domestic (United States and Canada) release of CSP-Kerberos includes encryption software in libcrypto.a. The International release does not.
Debugging CSP-Kerberos problems can be a complex task. The following mechanisms are designed to assist administrators in tracking down CSP-Kerberos problems:
Most implementations of the CSP-Kerberos server include tracing mechanisms that write messages to log files.The CSP-Kerberos server process writes messages to the /var/log/kadmin.log file; the Kerberos KDC process writes to the /var/log/krb5kdc.log file; and the default log file is /var/log/krb5lib.log for other log entries. These files can contain useful information concerning CSP-Kerberos error conditions.
Logging is controlled by a section of the krb5.conf file, reproduced here:
[logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log |
These log file locations can be changed by altering this section of the /etc/krb5.conf file.
The CSP-Kerberos libraries are equipped with several compiled-in debug flags, which can be set from applications, and they tell the library to print relevant information to stderr. Currently, there are two flags: krb_debug and krb_ap_req_debug. The former is designed primarily for administrators who might be expected to have a more detailed understanding of the CSP-Kerberos libraries; the latter is designed primarily for application developers.
To use the debug flags from within a user's program, place the following code in the user's program:
extern int krb_debug;
extern int krb_ap_req_debug;
main()
{
/* variable declarations here...*/
krb_debug = 1;
krb_ap_req_debug = 1;
/* the rest of the code here */
}
|
This code tells the library that the user wants to see the diagnostic information. Some diagnostic information may be written to the /var/log/krb5lib.log file on your system when this level of debugging is enabled.
| Note: The /var/log directory must exist for this log file to be created. |
The following is a list of common error messages that may be encountered when installing and running CSP-Kerberos. Each message is followed by an explanation.
| program : Could not get ticket for realm realm instance instance. No ticket file tf_util |
| |
| krb_sendauth failure or krb_mk_req: get_ad_tkt failed |
| |
| program: Authentication failed |
| |
| Principal unknown (csp-kerberos) |
| |
| program : Could not get ticket for realm realm, instance instance: Principal unknown |
| |
| Retry count exceeded (send_to_kdc) |
| |
| kpasswd: Could not connect to server attempting to change password |
|
This CSP-Kerberos implementation has several known weaknesses. Some of these weaknesses are specific to the IRIX operating system; however, most of them are problems of the CSP-Kerberos version 5 protocol or the CSP-Kerberos authentication paradigm. The weaknesses are as follows:
Time synchronization is not secure.
Because CSP-Kerberos uses encrypted time stamps as part of its replay detection scheme, CSP-Kerberos replay detection can be broken if the protocol used to synchronize the system clock can be broken. That is, a user who steals a ticket that was good for last Friday cannot try to use it directly, because CSP-Kerberos can detect that it has expired; however, if the user can get the system to think that it is last Friday, CSP-Kerberos will be unable to detect that the ticket has expired.
This implementation of the network time protocol (NTP) does not provide any sort of authentication mechanism to ensure that the clock updates it receives are genuine; therefore, it could be tricked into setting its clock back.
Newer versions of NTP support authenticated updates, but the authentication is clumsy and requires nontrivial efforts to be put into key management issues.
Ticket information is stored in a file.
CSP-Kerberos tickets are kept in files named /tmp/tkt_uid on the IRIX file system. These files have permissions of 600 and are owned by the user; however, this mechanism is not entirely secure. For example, any user with root privileges can read and even modify the contents of the ticket file.
Tickets must be stored on the client, either on disk or in memory. These locations are vulnerable to an attack by root.
By itself, the ticket does not allow the malicious user to impersonate the legitimate user. All CSP-Kerberos servers insist on receiving an authenticator in addition to a valid ticket. The authenticator is a message encrypted by the session key stored in the ticket. Unfortunately, the session key is stored along with the ticket in the user's ticket file; therefore, anyone who can read the ticket can read the key and build an authenticator from it.
The tickets are kept in /tmp intentionally. It is inadvisable to allow ticket files to survive beyond the lifetime of the user session that created them, and even less advisable for them to survive across system reboots.
Server key information is stored in a file.
Like ticket information, CSP-Kerberos stores server password information in a file, /etc/v5srvtab, which should be installed with permissions of 600 and should be owned by root. However, users gaining access to this file could use the information to create and install their own fake CSP-Kerberos servers. These servers would not be detectable by client processes, even those requesting two-way authentication.
Automatic replay detection is not available.
The MIT Kerberos implementers have not released the code for krb_ck_repl; the routine that checks for replay attempts. Users who want to check for replays must have their servers cache their own tickets and authenticators.
CSP-Kerberos passwords are subject to offline, brute force attacks.
A person can use kinit(1) to request CSP-Kerberos to send a packet encrypted with the key derived from any user's password. The cryptographer can then take this packet and attempt to break its encryption at his or her leisure. Although there is currently no well known way to break the DES encryption quickly, the cryptographer could always try a brute force sequential search. This is different from an online attack, in which someone tries to use brute force to break into a IRIX account by guessing passwords. The login sequence can be used to slow down the online attack, throwing the cryptographer off the system after some number of failed attempts. Offline attacks on CSP-Kerberos passwords are analogous to stealing the /etc/password file, and then trying to determine passwords by comparing the password field in the entry to encrypted words from a dictionary. This sort of attack occurs offline, with no system regulation.
For further reading on CSP-Kerberos security limitations, see “Limitations of the Kerberos Authentication System” by S. M. Bellovin and M. Merritt. This paper is available through anonymous FTP at the athena-dist.mit.edu site. It is found in the pub/kerberos/doc/usenix.PS file.