ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/kerberos-faq/user

Text File | 1995-09-20 | 34.8 KB | 746 lines

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!pad-thai.cam.ov.com!suan-la-chow-show.cam.ov.com!not-for-mail
From: [e-mail] (Barry Jaspan)
Newsgroups: comp.protocols.kerberos,comp.answers,news.answers
Subject: Kerberos Users' Frequently Asked Questions 1.14
Supersedes: <kerberos-faq/[e-mail]>
Followup-To: poster
Date: 19 Sep 1995 12:16:09 -0400
Organization: OpenVision Technologies
Lines: 726
Approved: [e-mail]
Expires: 17 Oct 1995 16:16:09 GMT
Message-ID: <kerberos-faq/[e-mail]>
NNTP-Posting-Host: suan-la-chow-show.cam.ov.com
Summary: This document answers Frequently Asked Questions
        about the Kerberos authentication system.  Read
        this before you post a question to
        comp.protocols.kerberos or [e-mail].
Xref: senator-bedfellow.mit.edu comp.protocols.kerberos:5469 comp.answers:14373 news.answers:53325

Archive-name: kerberos-faq/user
Version: 1.14



                  Kerberos Users' Frequently Asked Questions

September 14, 1995
Compiled by: Barry Jaspan, <[e-mail]>
OpenVision Technologies

     Kerberos; also spelled Cerberus. n. The watch dog of Hades, whose
     duty it was to guard the entrance--against whom or what does not
     clearly appear; . . . it is known to have had three heads. . .

     -Ambrose Bierce, The Enlarged Devil's Dictionary

This document answers Frequently Asked Questions about the Kerberos
authentication system. It is freely distributable. Direct all responses and
questions to [e-mail]. Most of the information presented here has
been collected from postings to the comp.protocols.kerberos newsgroup
(gatewayed to the mailing list [e-mail]).

DISCLAIMER: OpenVision Technologies makes no representations about the
suitability of this information for any purpose. It is provided "as is" without
express or implied warranty. In particular, this document is not intended as
legal advice for exporting Kerberos, DES, or any other encryption software.

Release Notes: The Web version of this document (
http://www.ov.com/misc/krb-faq.html) is now the master version. ASCII versions
will continue to the posted to news.answers and comp.answers and archived on
RTFM.MIT.EDU as before.

-------------------------------------------------------------------------------
Questions addressed in this release:

1. Kerberos and its Many Incarnations

(1.0) Where can I get more information?
(1.1) What is Kerberos? What is it good for?
(1.2) What different versions and distributions of Kerberos exist?
(1.3) Where can I get Kerberos version 4 or 5?
(1.4) What is the current status of version 4?
(1.5) What is the current status of version 5?
(1.6) Are version 4 and version 5 compatible?
(1.7) How/why is Transarc's Kerberos different from MIT Kerberos V4?
     Can they interoperate?
(1.8) How/why is OSF DCE Security different from MIT Kerberos V5?
     Can they interoperate?
(1.9) How/why is DEC Ultrix Kerberos different from MIT Kerberos V4?
     Can they interoperate?
(1.10) What is Bones? What is it for?

2. Building, Using, Installing, and Administering Kerberos

(2.1) Can I use Kerberos for local password validation?
(2.2) What is the export status of Kerberos?
(2.3) How can I delete a principal from the database?
(2.4) What are the officially assigned Kerberos port numbers?
(2.5) Are there Kerberos versions of telnet and ftpd?
     What other Kerberos clients exist?
(2.6) Why does rlogin print "Warning: No Kerberos tickets obtained"?
(2.7) What vendors provide commercial support for Kerberos?
(2.8) Why do I get an error message from ld when make_commands is executed?
(2.9) What is libkrb.a, and why can't ld find it?
(2.10) How do I set up a slave server?

4. Miscellaneous

(4.1) List references for Kerberos and network security in general.
(4.2) Where are archives of comp.protocols.kerberos (a.k.a
     [e-mail])?

-------------------------------------------------------------------------------

1. Kerberos and its Many Incarnations

(1.0) Where can I get more information?

The Kerberos mailing list is [e-mail]. There is a bi-directional
gateway between the list and the newsgroup comp.protocols.kerberos. Send
subscription requests to [e-mail].

*** PLEASE DO NOT SEND SUBSCRIPTION REQUESTS TO [e-mail]. ***

There are a number of Kerberos-related WWW sites. In no particular order:

   *  < http://www.ov.com/misc/krb-faq.html>. This FAQ, of course.
   *  < http://www.contrib.andrew.cmu.edu/usr/shadow/kerberos.html>. This site
     contains links to a variety of other documents, some about Kerberos, some
     related Kerberos, and some unrelated to Kerberos.
   *  < http://nii.isi.edu/info/kerberos>. This site contains references to
     Kerberos documentation and technical papers, available Kerberos
     distributions, Kerberos-related applications (only NetCheque, currently),
     and Kerberos vendor information from this FAQ.
   *  < http://pscinfo.psc.edu/~studarus/Kerberos>. This site contains
     information on setting up Kerberos V5 to use Sandia kadmin, the
     r-commands, and the sample server.
   *  < http://ubvms.cc.buffalo.edu/~tkslen/kerberos.html>. This site contains
     installation and configuration notes and help as well as pointers to a
     variety of other documents.

(1.1) What is Kerberos? What is it good for?

Kerberos is a network authentication system for use on physically insecure
networks, based on the key distribution model presented by Needham and
Schroeder.[3] It allows entities communicating over networks to prove their
identity to each other while preventing eavsdropping or replay attacks. It also
provides for data stream integrity (detection of modification) and secrecy
(preventing unauthorized reading) using cryptography systems such as DES.

Kerberos works by providing principals (users or services) with tickets that
they can use to identify themselves to other principals and secret
cryptographic keys for secure communication with other principals.[1] A ticket
is a sequence of a few hundred bytes. These ticket can then be embedded in
virtually any other network protocol, thereby allowing the processes
implementing that protocol to be sure about the identity of the principals
involved.

Practically speaking, Kerberos is mostly used in application-level protocols
(ISO model level 7), such as TELNET or FTP, to provide user to host security.
It is also used, though less frequently, as the implicit authentication system
of data stream (such as SOCK_STREAM) or RPC mechanisms (ISO model level 6). It
could also be used at a lower level for host to host security, in protocols
like IP, UDP, or TCP (ISO model levels 3 and 4), although such implementations
are currently rare, if they exist at all.

It is important to realize that Kerberos is a one-trick pony. It provides for
mutual authentication and secure communication between principals on an open
network by manufacturing secret keys for any requestor and providing a
mechanism for these secret keys to be safely propagated through the network.
Kerberos does not, per se, provide for authorization or accounting, although
applications that wish to can use their secret keys to perform those functions
securely. Kerberos also does not provide password validation for individual
workstations unless care is taken; see question 2.1.

It is also important to understand that using Kerberos on time-sharing machines
greatly weakens its protections, since a user's tickets are then only as secure
as the 'root' account (read: not very). Furthermore, dumb terminals and most X
terminals do not understand the Kerberos protocol and as a result their cable
connections remain insecure.

(1.2) What different versions and distributions of Kerberos exist?

There are several different versions and distributions of Kerberos. Most of
them are based on an MIT distributions in one form or another but the lineage
is not always simple. Some of the distributions are freely available, some are
stand-alone commercial products, and others are part of a larger free or
commercial systems. This list is certain to be incomplete:

Versions of Kerberos V4:

   *  MIT Kerberos V4. Freely available; see question 1.4.
   *  Bones. Freely available; see questions 1.3 and 1.10.
   *  Transarc AFS. Commercial; see question 1.7.
   *  Digital Unix. Commercial; see question 1.9.
   *  Also see question 2.7.

Versions of Kerberos V5:

   *  MIT Kerberos V5. Freely available; see question 1.5.
   *  OSF DCE Security. Commercial; see question 1.8.
   *  Also see question 2.7.

(1.3) Where can I get Kerberos version 4 or 5?

In the United States and Canada (*), Kerberos is available via anonymous FTP
from athena-dist.mit.edu (18.71.0.38). For specific instructions, cd to
pub/kerberos and get the file README.KRB4 (for version 4) or README.KRB5_BETA5
(for version 5). Note that *YOU WILL NOT BE ABLE TO RETRIEVE KERBEROS WITHOUT
READING THIS FILE*.

Outside the United States, you can get Bones via anonymous ftp from
ftp.funet.fi (128.214.6.100) in pub/unix/security/kerberos. A DES library is
available from the same place. See question 1.10 for information on Bones.

(*) Kerberos and DES can be exported to Canada. See question 2.2.

(1.4) What is the current status of version 4?

With the release of patch level 10 on December 10, 1992, MIT Kerberos 4 is now
in its final form. MIT does not anticipate ever making a new Kerberos 4
release.

Several vendors provide their own versions of Kerberos which may contain
improvements or extensions; see question 2.7.

(1.5) What is the current status of version 5?

The newest version of MIT Kerberos V5 is beta 5, released 5 May 1995. It
contains substantial (and backwards-incompatible) changes to the krb5 API, a
new admin server, improved portability, and numerous bug fixes and
improvements.

See question 1.3 for instructions on acquiring it.

(1.6) Are version 4 and version 5 compatible?

No. Versions 4 and 5 are based on completely different protocols. The MIT
Kerberos V5 distribution contains some compatibility code, however: (a) the
Kerberos server can optionally service V4 requests; (b) there is a program to
convert a V4 format Kerberos database to a V5 format database; (c) an
administration server that accepts V4 requests and operates on a V5 database is
provided.

(1.7) How/why is Transarc's Kerberos different from MIT Kerberos V4?
     Can they interoperate?

This is a fairly complex question, and this answer is known to be incomplete.
The issue is regularly discussed on the [e-mail] mailing
list; send mail to the -request list for subscriptions.

Years ago, the designers of AFS decided to implement their own security system
based on the Kerberos specification instead of using the (then, not yet
publicly available) MIT Kerberos V4. As a result, Transarc's AFS Kerberos
speaks a different protocol but also understands the MIT Kerberos V4 protocol.
They can, in principal, talk to each other; however, there are a sufficient
number of annoying details and an insufficient number of advantages such that
it may not be practical.

The two versions use a different string-to-key function (the algorithm that
turns a password into a DES key); the AFS version uses the realm name as part
of the computation while the MIT version does not. A program that uses a
password to acquire a ticket (e.g. kinit or login) will only work with one
version, unless it is hacked up to try both string-to-key algorithms.

The two versions also use a different method of finding Kerberos servers. MIT
Kerberos uses krb.conf and krb.realms to map hostnames to realms and realms to
Kerberos servers. AFS kaservers for a realm, by definition, are located on the
AFS database servers and can therefore be located using
/usr/vice/etc/CellServDB. This means that a program built using the MIT
Kerberos libraries will look in one place for the information while a program
built using the AFS Kerberos libraries will look in another. You can certainly
set up all three files and use both libraries, but be sure that everything is
consistent.

The two versions have a different password changing protocol, so you must use
the correct 'kpasswd' program for the server you are talking to. In general,
AFS clients that talk directly to the kaserver use an Rx-based protocol,
instead of UDP as with MIT Kerberos, so those AFS clients cannot talk to an MIT
server.

In summary, AFS Kerberos and MIT Kerberos can interoperate once you've acquired
a ticket granting ticket, which you can do with kinit (MIT) or klog (AFS). With
a tgt, Kerberos applications such as rlogin can talk to an MIT or AFS Kerberos
server and achieve correct results. However, it is probably best to pick one
implementation and use it exclusively.

(1.8) How/why is OSF DCE Security different from MIT Kerberos V5?
     Can they interoperate?

[ This answer is based on information provided by Joe Pato
([e-mail]). ]

DCE Security is based on Kerberos V5, and uses the same wire protocol for AS
and TGS requests; that means that standard Kerberos applications like kinit and
telnet should work using a DCE Security Server. The implementation for the DCE
Security Server, secd, was based on an early MIT releases and has evolved
independently of the MIT code base and as a result some minor incompatibilities
exist. DCE 1.2 slated for release in 1996 is planned to be fully conformant
with IETF RFC 1510 at which time any remaining protocol nits will be resolved
(interoperability problems with "vanilla" Kerberos clients will be treated as
bugs in DCE).

An MIT Kerberos V5 server cannot replace the DCE Security Server, however.
First, DCE applications communicate with secd via the DCE RPC. Second, the DCE
security model includes a Privilege Server (PS) that fills in the authorization
field of a principal's ticket with DCE-specific data, and the DCE Security
Server has a PS built in. In order for the MIT Kerberos V5 server to support
DCE clients it would need to talk to a stand-alone PS and, although the
necessary information is available, no such PS presently exists.

The DCE does not support the Kerberos V5 API. It does, however, provide the
GSS-API with Kerberos V5 mechanism (in addition to a DCE mechanism). Since a
Kerberos V5 GSS-API mechanism is also provided in the current MIT Kerberos V5
distribution, applications developed against the GSS-API with this mechanism
should operate with either an MIT Kerberos server or a DCE secd. For this
reason, the GSS-API should now be considered the API of choice for Kerberos
application development.

(1.9) How/why is DEC Ultrix Kerberos different from MIT Kerberos V4?
     Can they interoperate?

DEC ULTRIX contains Kerberos for a single reason, namely, to provide
authenticated name service for the ULTRIX enhanced security option. It does not
support user-level authentication in the normal manner.

DEC's version is essentially the same as (and derived from) MIT Kerberos V4
with a few changes. The most significant change is that the ability to perform
any kind of end-to-end user data encryption has been eliminated in order to
comply with export restrictions. Minor changes include the placement of ticket
files (/var/dss/kerberos/tkt vs. /tmp) and the principal names used by some
standard Kerberos services (e.g.: kprop vs. rcmd); there are probably other
minor changes as well.

These changes make it annoying but not impossible to use DEC ULTRIX Kerberos in
the normal way. However, there is no reason at all to do so, because the MIT
distribution supports ULTRIX directly. [This may not be completely true. I
imagine that using ULTRIX Kerberos for enhanced security and MIT's Kerberos at
the same time would cause problems. Has anyone tried this?]

(1.10) What is Bones? What is it for?

Bones is a system that provides the Kerberos API without using encryption and
without providing any form of security whatsoever. It is a fake that allows the
use of software that expects Kerberos to be present when it cannot be.

Why does it exist? Kerberos is a network security system which relies on
cryptographic methods for its security. Since Kerberos' encryption system, DES,
is not exportable, Kerberos itself cannot be exported or used outside of the
United States in its original form. (See question 2.2 for more information.)

As a partial solution to this problem, the Kerberos source code was modified by
the addition of #ifdef NOENCRYPTION around all calls to DES functions.
Compiling this version with the symbol NOENCRYPTION defined results in a system
that looks like Kerberos from an application's point of view but that does not
require DES libraries (and, as a result, does not speak the real Kerberos
protocol and does not provide any security).

The final piece in this puzzle is a program called "piranha" which takes the
Kerberos sources and removes all of the calls to the encryption routines,
replacing it with the code which was under #ifdef NOENCRYPTION, producing the
system known as Bones. Bones has the property that there is absolutely no
question about whether or not it is legal to transport its sources across
national boundaries, since it neither has any encryption routines nor any calls
to encryption routines.

#ifdef NOENCRYPTION was not documented, and it was only intended to be used in
the above manner. Someone who tries compiling Kerberos with that #define has in
some sense "voided the warranty", and will get something which is both (a) not
secure and (b) not Kerberos.

Copies of the Kerberos Bones with DES routines and calls added back in by
foreign programmers are called `eBones', and are available by anonymous FTP
from machines in Sweden, Germany, Israel, Finland, Australia, and France (so
far); check with "archie".
-------------------------------------------------------------------------------

2. Using and Administering Kerberos

(2.1) Can I use Kerberos for local password validation?

Yes, but only under certain circumstances and only if you are careful.

Requests for Kerberos ticket granting tickets (tgts) (e.g. from kinit or login)
are sent in plaintext to the Kerberos server, which then responds with
credentials encrypted in the requesting principal's secret key. The program
then attempts to decrypt the data with the supplied password and considers the
authentication "successful" if the decryption appears to yield meaningful
results (such as the correct principal name).

The problem here is that the requesting program cannot know for sure whether
the decryption succeeded or, more importantly, whether the response actually
came from the Kerberos server. An attacker could, for example, walk up to an
unattended machine and "log in" as a non-existent user. Kerberos will
eventually respond with an appropriate error, but the attacker can arrange for
another program to deliver a fake response to login first; he then types the
correct password (which he knows because he created the fake response in the
first place) and succeeds in spoofing login.

The solution to this problem is for login to verify the tgt by using it to
acquire a service ticket with a known key and comparing the results. Typically,
this means requesting an rcmd.<hostname> ticket, where <hostname> is the local
hostname, and checking the response against the key stored in the machine's
/etc/srvtab file. If the keys match then the original tgt must have come from
Kerberos (since the key only exists in the srvtab and the Kerberos database),
and login can allow the user to log in.

The solution works only so long as the host has a srvtab containing an
rcmd.<hostname> (or any other standard principal) entry. This is fine for
physically secure or single-user workstations, but does not work on public
workstations in which anyone could access the srvtab file.

(2.2) What is the export status of Kerberos?

[ There is a great deal of activity relating to this question and the answer
below is somewhat out of date. ]

The export status of Kerberos is unclear, largely because the export
regulations are unclear in general. There's an overview of cryptography export
cases in http://www.cygnus.com/~gnu/export.html .

Several companies, including OpenVision and DEC, have received export licenses
for commercial products that contain Kerberos binaries and/or programming
libraries. Contact the Kerberos vendors listed in question 2.7 for more
information.

Export of technology is controlled by both the State Department and by the
Commerce Department. The two agencies' jurisdictions don't actually legally
overlap, but nobody really knows which agency has jurisdiction over which
products. So there is a process by which you, as a potential exporter, can ask
the State Department which agency controls your particular export. It's called
a Commodity Jurisdiction Request or CJR. There is a "CJR Kit" for helping you
to file CJR's available at ftp://ftp.cygnus.com/pub/export/cjr.kit .

The State Department has the power to regulate exports of even publicly
available (published) materials, in apparent contradiction to the First
Amendment. The Commerce Department regulations (Commerce Control List)
specifically exempts publicly available materials from export controls (section
779.3), allowing their export under `General License' GTDA, which requires no
paperwork and is usable by everyone except a few hundred people or companies
who have abused export controls in the past. The State Department regulation
(International Traffic in Arms Regulations, or ITAR) exempts `public domain
information' (22 CFR 120.11) but fails to define `information'. The State
Department takes the position that software is not `information'.

Kerberos is an authentication system, and export of authentication software and
hardware is controlled by the Commerce Department. However, the State
Department has never formally said where the line between authentication and
encryption is, so they are also apparently interested in Kerberos.

Cygnus Support filed a CJR for the Kerberos Bones software, and got back a
formal notification that it was controlled by the Commerce Dept. We then filed
a CCATS request with the Commerce Department, and eventually found out that it
is exportable to all destinations without paperwork under the GTDA license
(because it is `publicly available' without charge on the Internet). The formal
documents are in ftp://ftp.cygnus.com/pub/export . This just confirms what we
all suspected anyway -- if you take the crypto out of Kerberos (which is how
the Bones were generated), it's exportable. The Bones are available at
ftp://athena-dist.mit.edu/pub/kerberos; look at README.ftp for instructions.

As for the exportability of full strength Kerberos in source code, nobody has
apparently applied for this. (Please let us know if you know of a case.)

I believe that the best bet for threading the export maze is to define and
defend Kerberos as an authentication product, to get it past the State
Department, and then to show that it is publicly available, to get it past the
Commerce Department. To do this, you actually have to be trying to export a
publicly available version of Kerberos, though.

Canada is considered a part of the United States for export control purposes so
Kerberos can be exported to Canada without problems.

(2.3) How can I delete a principal from the database?

MIT Kerberos V4 does not include a single command to delete a Kerberos
principal. This was an intentional omission based on the assumption that by
making deletion difficult, accidents were less likely to happen. If you want to
delete a principal, do "kdb_util dump", edit the ASCII dump with an editor, and
do a "kdb_util load". Obviously, you can write a shell script to make this more
convenient.

The admin tools for AFS Kerberos, MIT Kerberos V5, DCE Kerberos, and virtually
every commercial version of Kerberos have a delete command.

(2.4) What are the officially assigned Kerberos port numbers?

The file src/prototypes/services.append in the MIT Kerberos distribution
contains the commonly used port assignments. This file is not the whole story,
however.

"kerberos" has officially been moved to port 88, although people will have to
listen on port 750 for some time to come, and assume that many servers won't be
converted to listen to port 88 for some time.

"kerberos_master" and "krb_prop" have not been reserved, but they are only used
for intra-site transactions so having them reserved probably isn't necessary.
Furthermore, both of their port numbers have already been assigned to other
services, so requesting an official assignment will force them to change.

"eklogin", "kpop", and "erlogin" have not been officially reserved, but
probably should be. Their ports are not currently assigned to other services,
so hopefully they will not have to change if an official assignment is
requested.

(2.5) Are there Kerberos versions of telnet and ftpd?

(a) TELNET. An experimental Telnet Authentication Option has been defined, and
is described in RFC1416. A separate document, RFC1411, describes how that
option is to be used with Kerberos V4, but no RFC exists for its use with
Kerberos V5. These RFC's only define how authentication is to be performed; the
standard for full encryption is still under development.

An implementation of Kerberos V4 telnet is available via anonymous ftp from
ftp.uu.net, in /networking/telnet.91.03.25.tar.Z, but it predates both of the
above-mentioned RFCs and is therefore almost certainly not compliant with them.
A Kerberos V5 telnet implementation is contained in MIT Kerberos 5 beta 4 and
subsequent releases.

(b) FTP. The IETF Common Authentication Technology (CAT) Working Group has
published the Internet Draft "FTP Security Extensions"
<draft-ietf-cat-ftpsec-NN.txt> which defines Kerberos V4 and GSS-API
authentication systems. Please note that the extensions are still in the Draft
stage and may change at any time, in incompatible ways.

A freely available version of FTP using Kerberos V4 used to exist on
thumper.bellcore.com but is no longer there [Anyone know where it went?].
Commercial versions of secure FTP are available; see question 2.7.

(2.6) Why does rlogin print "Warning: No Kerberos tickets obtained"?

Kerberos rlogin uses a standard Kerberos exchange to prove the identity of the
user to the remote host, after which it uses the /etc/passwd and a .klogin file
to determine whether the user is authorized to log in.

Since the user never types a password, klogind on the remote host cannot obtain
a new ticket granting ticket. The user's existing tgt cannot be used on the
remote host, because MIT Kerberos V4 tickets are host-specific. Therefore, even
though the user has logged in to the remote host, there is no ticket granting
ticket for the user available on the remote host. The warning message is merely
a reminder of this fact.

The most recent release of MIT Kerberos V4 (patchlevel 10) contains a system
called "rkinit" that allows a user to obtain a ticket granting ticket on a
remote machine. Using this system, it is possible first to obtain a tgt on a
machine and then log into it with Kerberos rlogin, thereby achieving a secure
remote login with tickets. Alternatively, you use Kerberos V5 which has
forwardable tickets. However, forwardable tickets do not seem to work in the
current release of MIT Kerberos V5.

(2.7) What vendors provide commercial support for Kerberos?

This answer contains contact information for Kerberos vendors. Any vendor can
submit an entry.

NOTE: The current author of this list works for OpenVision Technologies, Inc.

----------------------------------------

Vendor:         CyberSAFE Corporation
                formerly Open Computing Security Group (OCSG)
Product:        Challenger
Contact:        Sales Department
                [phone]
                [e-mail]
Base version:   MIT Kerberos 5
Last update:    4/6/95

----------------------------------------

Vendor:         Cygnus Support
Product:        Cygnus Network Security (CNS)
Contact:        Dwayne Shirakura or Kathy Powers
                   [phone]  voice
                   [phone]  fax
                   [e-mail]
Base version:   MIT Kerberos 4
Last update:    4/20/95

References:
           o Product information: <http://www.cygnus.com/data/cns.html>

----------------------------------------

Vendor:         Digital Equipment Corporation
Product:        DECathena
Contact:        Steve Omand
                [phone]
                [e-mail]
Base version:   MIT Kerberos 4
Last update:    4/11/95

References:
        ftp://ftp.digital.com/pub/Digital/info/whitepaper/decathena-solution.*
        ftp://ftp.digital.com/pub/Digital/info/whitepaper/secure-distributed-computing.*
        http://www.digital.com/info/whitepaper/decathena-solution.abs.html
        http://www.digital.com/info/whitepaper/secure-distributed-computing.abs.html

----------------------------------------

Vendor:         Emulex Network Systems
Product:        a line of communications servers
Contact:        [phone] ext 8065
                [e-mail]
Base version:   MIT Kerberos 4
Last update:    11/23/94

----------------------------------------

Vendor:         OpenVision Technologies, Inc.
Product:        OpenV*Secure
Contact:        Brian Breton
                [phone] (voice)
                [phone] (fax)
                [e-mail]
Base version:   MIT Kerberos 5
Last update:    7/18/95

References:
        o Product information: <http://www.ov.com/product/>
        o Technical paper: _GSS-API Security for ONC RPC_
                <ftp://ftp.cam.ov.com/pub/users/bjaspan/rpc_paper.ps>

----------------------------------------

Vendor:         TGV, Inc.
                101 Cooper Street
                Santa Cruz, CA  95060
Product:        MultiNet for OpenVMS V3.3 Rev D
Contact:        [phone]
                [e-mail], [e-mail]
Base version:   MIT Kerberos 4
Last update:    1/20/95

----------------------------------------

Vendor:         Xyplex, Inc.
                295 Foster St.
                Littleton, MA 01460
Product:        terminal servers
Contact:        [phone]
                [phone] (fax)
                [e-mail]
Base version:   MIT Kerberos 4 and 5
Last update:    4/17/95

----------------------------------------

(2.8) Why do I get an error message from ld when make_commands is executed?

The make_commands program (from the file util/ss/make_commands.c, around line
101) spawns ld as part of its normal operation. The arguments to ld are
hard-coded into the exec() call and are not correct for all systems. To fix the
problem, examine the call and determine the correct arguments for your
environment; once you know the correct arguments, the change to the source code
will be obvious.

(2.9) What is libkrb.a, and why can't ld find it?

The MIT Kerberos V5 server (krb5kdc) can operate in a V4 compatibility mode in
which it accepts and responds to standard V4 requests (see question 1.5). In
order to do so, it needs the V4 Kerberos library, libkrb.a. That library is not
part of the V5 beta 4 and earlier distributions. It is assumed that if you want
V4 compatibility you already have V4 built and installed; see question 1.3 for
information on obtaining V4. To get krb5kdc to link properly, run configure
with the argument "--with-krb4=" where is a directory that contains directories
called "include" and "lib" that contain the V4 include files and libraries.

Starting with the beta 5 release, the MIT Kerberos V5 distribution contains the
V4 code so it is no longer necessary to obtain and build it separately.

(2.10) How do I set up a slave server?

This answer is written for Kerberos V5, but the same setup works for V4 with
different program names.

A slave database propagation consists of four steps:

  1.  Dumping the database to a transportable form. Use the command as
     "kdb5_edit -R 'dump_db /krb5/slave_datatrans'".
  2.  Transmitting the file from the master server with kprop. Use the command
     "kprop " for each slave server you want to propagate to. This requires
     that the master's host principal appear in the master's keytab (e.g.:
     /etc/v5srvtab).
  3.  Receiving the file on each slave server with kpropd. kpropd is intended
     to be run out of inetd with a line such as

     krb5_prop stream tcp nowait root /var/sbin/kpropd kpropd -p
     /var/sbin/kdb5_edit

     kpropd requires that the slave server's host principal exist in its
     keytab.
  4.  Loading the transported database with kdb5_edit load. If everything goes
     well up to this point, kpropd will automatically invoke kdb5_edit (via the
     path you specified in /etc/inetd.conf) and load the database so that the
     slave KDC can use it.

Given this system, all you have to do is make sure that a krb5kdc gets started
on all of your slave servers and that the propagation takes place at whatever
schedule you desire. A common solution is to write a script to perform steps 1
and 2 above that is run from cron(1).

-------------------------------------------------------------------------------

4. Miscellaneous

(4.1) List references for Kerberos and network security in general.

See the bibliography at the end of this document.

(4.2) Where are archives of comp.protocols.kerberos (a.k.a
     [e-mail])?

Archives are available via anonymous FTP from athena-dist.mit.edu in the
directory pub/kerberos/krb-mail. The [e-mail] archives presently extend
up to the end of 1992. Some archives of the kerberos protocol mailing list are
also available.

-------------------------------------------------------------------------------

BIBLIOGRAPHY

The FTP site for a reference, when known, is listed in square brackets
following the entry. Yes, I know that these are not in Officially Blessed
Bibliography Format. Sue me.

[1] Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller. "Kerberos: An
Authentication Service for Open Network Systems", USENIX Mar 1988.
[athena-dist.mit.edu:pub/kerberos/doc/usenix.PS]

[2] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, "Kerberos
Authentication and Authorization System", 12/21/87.

[3] R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in
Large Networks of Computers," Communications of the ACM, Vol. 21(12), pp.
993-999 (December, 1978).

[4] V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level Network
Protocols," Computing Surveys, Vol. 15(2), ACM (June 1983).

[5] Li Gong, "A Security Risk of Depending on Synchronized Clocks", Operating
Systems Review, Vol 26, #1, pp 49--53.

[6] S.M. Bellovin and M. Merritt, "Limitations of the Kerberos Authentication
System," USENIX Jan 1991.
[research.att.com:dist/internet_security/kerblimit.usenix.ps]

[7] Refik Molva, Gene Tsudik, Els Van Herreweghen, and Stefano Zatti,
"KryptoKnight Authentication and Key Distribution System."
[jerico.usc.edu:pub/gene/www/paps/mtvz.ps.Z]

[8] C. Neuman and J. Kohl, "The Kerberos Network Authentication Service (V5),"
RFC 1510, September 1993.

[9] B. Clifford Neuman and Theodore Ts'o, "Kerberos: An Authentication Service
for Computer Networks," IEEE Communications, 32(9), September 1994.
[http://nii.isi.edu/publications/kerberos-neuman-tso.html]

-------------------------------------------------------------------------------
Barry Jaspan,
[e-mail]

OpenVision Technologies
--
Barry Jaspan, [e-mail]
OpenVision Technologies