Kerberos Authentication

Kerberos is a "trusted third party" authentication system developed at MIT which allows clients and servers to authenticate and communicate securely over an untrusted network. It uses symmetric-key encryption technology (DES) to avoid passwords being sent over the network in the clear. For an introduction to Kerberos, please see: Kerberos: An Authentication Service for Open Network Systems or The Kerberos FAQ.

Note: Kerberos V4 and V5 may be used simultaneously, in case you are in two realms (perhaps as a part of V4->V5 migration).

Advantages of using Kerberos

 Using kerberized web browsers and servers have the following advantages:

Compiling HTTPd with Kerberos support

 You will need to have the relevant Kerberos libraries and include files installed on your machine. So set the "KRB4DIR" and/or "KRB5DIR" defines in the HTTPd's Makefile (in the "src" directory) appropriately. Then be sure to un-comment the "KRBFLAGS" and "KRBLIBS" lines in this Makefile, since the default settings do not include Kerberos support.

You can compile HTTPd with support for Kerberos V4 and/or Kerberos V5 (yes they will coexist peacefully, if need be). If you only want one flavor, simply comment out the lines related to the other flavor. For example, if you want V5 support but not V4, comment out the Makefile lines for "KRB4DIR", "KRB4FLAGS", and "KRB4LIBS".

Syntax of .htaccess file

 To require Kerberos authentication for viewers of a particular document directory, you must assign AuthType to either KerberosV4 or KerberosV5. Then you can use the require lines to further specify allowed users.

Additional Configuration Steps

Make sure Kerberos is properly configured on the server machine

This means that your Kerberos configuration file(s) are installed and contain the appropriate realm name, host->realm mapping and such. For Kerberos V4, this involves the "krb.conf" and "krb.realms" files (usually in the "/etc/athena" directory); for Kerberos V5, this only involves the "krb5.conf" file (usually in "/etc").

Defining the "khttp" principal:

To use the kerberos features in HTTPd, your realm must have a principal defined for the "khttp" service on the server's machine. So if your realm is FOO.BAR.EDU and you want to run the kerberized HTTPd on a machine named howard.foo.bar.edu , there will need to be a kerberos principal named:

Note: if you have a DNS alias mapping the name "www.foo.bar.edu" to "howard.foo.bar.edu", you would want to use the "www" in your principal name.
Also note: there may be other ways of handling the instance field (the one with the server's host name) which work. The method explained above is the one that has been working well in our tests so far.

For details on how to add a new principal to your Kerberos database, please see the documentation that comes with your Kerberos package.

Setting up the server's keyfile

Once you have the "khttp" principal defined, you must make that principal's secret key available in a keyfile on the server's machine. To do this, a "srvtab" must be created using the Kerberos admin utilities ("kdb5_edit", for V5; "make_srvtab" or "ksrvutil" for V4). This srvtab file must be saved in a sensible location on the machine running HTTPd (see the "Defaults" section below). When you run HTTPd, you can (currently, you must) give it the srvtab filename(s) on the command line using the "-k" and/or "-K" options.

httpd -k /etc/athena/srvtab sets the Kerberos V4 keyfile to "etc/athena/srvtab"

httpd -k /etc/v5srvtab sets the Kerberos V5 keyfile to "etc/v5srvtab"

Important: Set the file permissions carefully

The security of your kerberized server depends on the handling of the keyfile. This file should only be readable by the web daemon (as well as "root"). Installing the keyfiles in the standard places (/etc) will probably require being root. However, it is unwise to have HTTPd run as root (see the options for "httpd.conf"). Here is one way to do things:

Alternatively, you could (as root) simply change the ownership of the keyfile to "web" and make it only readable by owner.

Files

Defaults

The HTTPd binaries are compiled without Kerberos features. The Makefile that comes with the source distribution also has Kerberos disabled, as a default.

Note that currently (beta 1), you must give the filename of the server's key as a command line argument to HTTPd to make the kerberos features work. The default values for these filenames may not work (yes, a bug). In the future, this may become a configuration option. Please tell us how you would like this file specified.

Examples

Here is a sample .htaccess file in some document directory:

AuthType KerberosV4
<Limit GET>

order deny,allow
deny from all
allow from .ncsa.uiuc.edu
require valid-user
</Limit>

This grants access to any authenticated client in the server's Kerberos realm who are connecting from a machine in the ".ncsa.uiuc.edu" domain (double protection, if you will).

For More Information

If you have problems or questions, send email to the NCSA HTTPd group's Kerberos dude, acain@ncsa.uiuc.edu.

comming soon: documentation on using Kerberized Mosaic
in brief:

NCSA HTTPd Development Team / httpd@ncsa.uiuc.edu / 01-06-96