\input texinfo    @c -*-para-*-
@setfilename kerberos.info
@settitle CYGNUS SUPPORT for Kerberos

@node top, Introduction, (dir), (dir)

@menu
* Introduction::		Introduction to Cygnus Support
* Installation::		How to install Kerberos
* Administration::		How to Administer a Kerberos Realm
* Development::			How to Kerberize a network service
@end menu

@node Introduction, Installation, , top
@chapter Intro

Cygnus Support provides support for kerberos in many ways. Many levels.

@menu
* What is Cygnus::		Description of Cygnus Support
* Shrink Wrap::			Shrink wrap products
* Maintenance Support::		Administrative work
* Consulting Support::		Your needs turned into code
@end menu

@node What is Cygnus, Shrink Wrap, , Introduction
@section Description of Cygnus Support

Cygnus was founded in 198? to support Free Software. (define here)

@node Shrink Wrap, Maintenance Support, What is Cygnus, Introduction
@section Shrink wrap products

If you can deal with loading up a tape and following our instructions,
we can sell that to you.

@node Maintenance Support, Consulting Support, Shrink Wrap, Introduction
@section Administrative work

If you want us to plan everything out, we can do that too.

@node Consulting Support,  , Maintenance Support, Introduction
@section Your needs turned into code

If you've got a product to integrate, we can help you with it. If you've
got company-wide services that should be secured, we can plan or code
that for you as well.


@node Installation, Administration, Introduction, top
@chapter How to install Kerberos Support

There are several installation sets, depending on how much support you
need for a given machine.

@menu
* config::			How to make Configuration Decisions
* Client Support::		For end user workstations needing
				access to Kerberos services.
* Server Support::		For machines providing conventional
				network services, provide Kerberos
				replacements.
* Kerberos Master Server::	The central Kerberos security server.
* Kerberos Slave Server::	Live backups of the central server.
@end menu



@node config, Client Support, Installation, Installation
@section How to make Configuration Decisions

There are a number of decisions that you will need to make during the
installation of Kerberos. 

@menu
* Security Level::	What threat are you fighting
* Resources::		Server hosts, service hosts, disk space
* Naming::		Realm names, host names.
@end menu


@node Security Level, Resources, , config
@subsection What threat are you fighting

There are various ways to use Kerberos as part of an overall security
situation.

Security against outside attackers.

Security against inside attackers.

Convenience in a distributed workstation environment.

Augmenting an existing security organization.

Security against cryptographic attack.
	Kerberos uses DES in certain ways. The protocol takes into
account the risks of known plaintext and chosen plaintext attack. The
Biham and Shamir "Differential Cryptanalysis" attack, which requires
2^47 chosen plaintexts, is not an effective attack on Kerberos.

@node Resources, Naming, Security Level, config
@subsection Server hosts, service hosts, disk space

Kerberos does not require much disk space. Any client that is already
getting system software via NFS can get kerberos software the same way.
Any application server can do the same, though we expect most
application servers to have system software stored locally; there must
be a small amount of local space for the server private key (in the
srvtab file. @xref{Service entries}.)

The Kerberos master server itself needs enough disk space to hold the
key database, and for reliability reasons should have the kerberos and
kadmin servers locally.

MIT runs a site with over 10,000 users and 3,000 hosts with a MicroVAX
II master server and a few slaves. The slaves seem to only be getting
requests during network outages, which indicates that the master server
is not overloaded at this size.

@node Naming, , Resources, config
@subsection Realm names, host names.

If you are already using the Domain Name Service, which we recommend,
and you're only setting up one Kerberos Realm (ie. one administrative
authority -- size isn't an issue) then we suggest 
	Realm name: DNS domain name.
	Kerberos server name(s): kerberos (kerberos-1,2... etc.)

If you have multiple administrative areas that may need to work
together, you will still want to divide things in a similar manner to
which you've already divided your namespace. If the namespace is not
divided, you'll either need to explicitly list members of one domain in
the krb.realms file or you'll need to have users specify the -k argument
for most commands.


@node Client Support, Server Support, config, Installation
@section For end user workstations needing access to Kerberos services.

Everything in this install can be installed in a common location.
Applications provided are
	kinit
	klist
	kdestroy

	rlogin
	rcp
	rsh
	telnet

	ksu
	kadmin

	movemail
	pfrom


A pair of configuration files is needed to identify the realms the host
will need to communicate within.
	No special privacy is needed; standard precautions against
trojan horse attacks are useful.


1) Either install the release directly in /usr/kerberos, or set up
symbolic links or NFS mounts as your configuration warrants.

2) Generate krb.conf and krb.realms files with your local configuration
parameters. See @xref{config} for details.

3) Update /etc/services file.

@node Server Support, Kerberos Master Server, Client Support, Installation
@section For machines providing conventional network services.

Executables should be installed reliably (they may be shared between
machines, but this is unlikely to be a good idea.) Daemons provided
are
	klogind
	telnetd
	kshd
	popper
	ksrvutil

Along with the configuration files used in the client install, you'll
need to create a "srvtab"; @xref{Service entries}. If the srvtab is
compromised, it is possible to impersonate users and obtain access to
the services on this particular server.

Kerberos-enhanced network services can be installed simply by adding
entries for them to /etc/inetd.conf (on BSD derived systems.) However,
there are some systems which have trouble with a large number of service
entries, so a simple workaround is to run a second instance of "inetd",
the internet service daemon, with a configuration file containing the
Kerberos-enhanced services. On BSD derived systems, this inetd should be
started in /etc/rc.local using whatever idiom was used for the normal
inetd.

@node Kerberos Master Server, Kerberos Slave Server, Server Support, Installation
@section The central Kerberos security server.

Executables should be installed very reliably (preferably locally.)
Local disk space is also needed for the Kerberos Key Database. Programs
installed are
	kerberos
	kadmind
	kstash
	kdb_util
	kdb_edit
	kdb_init
	kdb_destroy
	kprop
	kpropd
	ext_srvtab

	Access to the memory or core dumps from this machine could
compromise security for the entire realm. If service is attended, the
kerberos master key can be entered at every reboot and not otherwise
recorded on disk; if so, normal backups can be made of the database. For
convenience, "kstash" can be used to store the master key on local disk;
care should be taken not to make this file accessible or to make
backups of it.

@node Kerberos Slave Server, , Kerberos Master Server, Installation
@section Live backups of the central server.

A slave server provides a live read-only copy of the database so that
key service is still available in case the master is down or overloaded.
Changes to the copy are not possible, and the server may lag the master
by some amount of time. Programs installed are
	kerberos
	kdb_util
	kprop
	kpropd
	kstash

Access restrictions are similar to the master server; media backups
would be redundant.

@node Administration, Development, Installation, top
@chapter How to Administer a Kerberos Realm

@menu
* User entries::		Keys for users
* Service entries::		Keys for services
* Administration Tools::	kadmin and other utilities
* Using Kerberos::		Kerberos for the User
@end menu


@node User entries, Service entries, , Administration
@section Keys for users

Users are "principals" in the database. Each principal has a secret key;
this key is only known to the user and to the kerberos server. The user
actually knows a password which is a string that is converted to a DES
encryption key; the server only stores the DES key, not the password
itself.

@node Service entries, Administration Tools, User entries, Administration
@section Keys for services

Services are also principals; typically, a service will use an
application name as the principal and the name of the host supporting
the service as the instance. The key for this entry is stored in the
kerberos database and in the "srvtab" file on the host providing the
service. 
	The initial key can be set with kadmin or kdb_util, and then
propagated to the application server with ext_srvtab or ksrvutil. After
propagation, ksrvutil change should be used to randomize the key.

@node Administration Tools, Using Kerberos, Service entries, Administration
@section kadmin and other utilities

While kdb_util and kdb_edit can be used directly on the server to change
the database, it is more convenient to simply add administrators to
ACL's for changing or adding to the database. An administrator needs to
have an "admin" instance; the kadmin program takes care of the details
from there.



@node Using Kerberos,  , Administration Tools, Administration
@section Kerberos for the User

@menu
* How it works::		How kerberos gives you secure access

* kinit::			Get initial Kerberos tickets
* kdestroy::			Purge current Kerberos tickets
* kpasswd::			Change your password

* rlogin::			Remote login to host (secured by kerberos)
* rsh::				Run remote commands (secured by kerberos)
* rcp::				Copy remote files (secured by kerberos)
* rdist::			Remote Distribution of files
@end menu

@node How it works, kinit, , Using Kerberos
@subsection How kerberos gives you secure access

The popular Berkeley networking software (rlogin, rsh, rcp) was
developed back when there were relatively small number machines on the
network, and they were expensive enough to be owned and managed by
central organizations rather than individuals. This meant that it was
reasonable to trust a machine when it claimed that some particular
person was using it.
	Today, there are a huge number of machines directly networked,
many of which are inexpensive enough to be owned by individuals or
left available for public access. This both makes it difficult to
trust individual machines over the network, since the machines may not
adequately verify the users on them, or the machine itself may have
been impersonated by another.
	Clearly trusting a machine at the other end of a wire is not
what is actually intended.  Machines merely function, *people* have
judgment.  Kerberos comes closer to the original model by basing
security on a "secret" which is shared between the KDC and the person.
This secret is a cryptographic key based on the user's password, with
which the user can prove who they are by being able to decrypt sealed
messages from the KDC.



@node kinit, kdestroy, How it works, Using Kerberos
@subsection Get initial Kerberos tickets

kinit prompts for your password, and gets you an "initial ticket" which
is normally valid for 10 hours.

@node kdestroy, kpasswd, kinit, Using Kerberos
@subsection Purge current Kerberos tickets

kdestroy purges the contents of your ticket file and then deletes the
file itself.

@node kpasswd, rlogin, kdestroy, Using Kerberos
@subsection Change your password

kpasswd allows you to change your Kerberos password, which may be
different from the one on your local machine. 
@node rlogin, rsh, kpasswd, Using Kerberos
@subsection Remote login to host (secured by kerberos)

rlogin has been enhanced to use kerberos to secure the connection. The
usage you are familiar with will continue to work, except that it will
trust your tickets rather than the host you are on. Your .rhosts file
will no longer be used; instead, the system will automatically trust
you, and optionally anyone whose kerberos principal you include in 
your .klogin file.

rlogin has a few options that the system rlogin doesn't have:

-x		encrypt the current session, so that it can't be
	monitored by anyone with access to the network.

-k realm	select a particular realm for the remote host (not
	generally used, as the krb.realms file should be configured
	correctly for any realm you're working with.)


@node rsh, rcp, rlogin, Using Kerberos
@subsection Run remote commands (secured by kerberos)

rsh has been enhanced in the same way that rlogin has, except that it
does not at this time support encryption.

@node rcp, rdist, rsh, Using Kerberos
@subsection Copy remote files (secured by kerberos)

rcp has been enhanced in the same way rlogin has, and includes the -x
option to encrypt the session. 


@node rdist,  , rcp, Using Kerberos
@subsection Remote Distribution of files (secured by kerberos)

rdist has *not* yet been kerberized. There are plans to do so.

@node Development,  , Administration, top
@chapter How to Kerberize a network service

There are a number of ways of adapting an existing service to the
Kerberos model. 

If the service is attended, then the authorization to use it will be
based on the user's Kerberos tickets. However, there is occasionally a
need to access a Kerberos service from a host; if that host can be
protected sufficiently, then it is possible to store a key on it and use
that to request Kerberos tickets.

If the service is already using Berkeley rsh as it's underlying
mechanism, you can simply use the Kerberos rsh instead. Likewise for
applications that use rcp.

If the service opens a network stream itself, it can use the "kcmd"
function to pass authentication information, and use our "kstream"
library to provide encryption if needed.

@bye
