Date: Fri, 30 Oct 92 14:19:43 EST
From: Steve Lunt <lunt@ctt.bellcore.com>
To: kerberos@Athena.MIT.EDU
(Sorry if you get this twice, not sure it went to everyone
the first time).
The following is a proposal for work on improving Kerberos
Version 5. Your input is requested should you be a potential user of
such a Kerberos product, or a potential contributor/developer of such
a product.
-- Steve
Steven J. Lunt | lunt@bellcore.com | RRC 1L-213
Information Technology Security |---------------------| 444 Hoes Lane
Bellcore | (908) 699-4244 | Piscataway, NJ 08854
_________________________________________________________________
0. PREAMBLE
The following are descriptions of feature enhancements for an
authentication system based on the Kerberos Version 5 protocol
which, in Bellcore's view, would make a Kerberos-based system
better able to provide enhanced security functionality for
commercial environments at Bellcore and at Bellcore Client
Companies.
We have submitted these enhancement descriptions to some vendors
to understand the implementation cost of such enhancements. If
you feel that these enhancements would also meet your needs and
wish to forward them to your security service vendors, you may do
so. We will also be happy to receive other non-proprietary
enhancement ideas and will consider adding them to possible
future issues of this document if, in Bellcore's view, they
provide additional needed functionality. The comments we hope to
receive from individuals and organizations involved in the area
of authentication would reveal whether the proposed set of
enhancements are of general interest and whether other features
of general interest should be added to this document.
1. INITIAL RELEASE - Proposed Enhancements
The following sections describe the enhancements for an initial
release to supplement the Kerberos software. This initial release
should be based on the beta release of Version 5 code of
September 30, 1992, publicly available enhancements and fixes, as
well as documentation. Enhancements outlined in Section 2 would
be deferred until a subsequent release which should follow the
initial release within one year. The beta release of the code is
available directly from MIT via anonymous FTP.
1.1. The Existing Code and Publicly-available Enhancements/Fixes
The beta release of the Version 5 code from MIT has been
augmented by additions and fixes provided in large part by Sandia
National Labs (see Section 1.4, Remote Administration Server).
1.2. Subsequent MIT Code Releases
Enhancements should be compatible with all new releases from MIT
for the baseline Kerberos Version 5 code.
1.3. Supported Platforms
The enhancements as well as the baseline code should operate on a
number of hardware platform / operating system combinations, as
needed by potential users, beyond the ones already supported by
the MIT code.
1.4. Remote Administration Server
A remote administration server is needed to deploy Kerberos,
since without it, users cannot change their passwords without
administrative intervention. A remote administration server,
contributed by Sandia National Labs, was included in the recent
beta release from MIT and should be tested by enhancement
providers.
1.5. Other Administration Utilities
1.5.1. Adding Kerberos to a New Host
Bellcore has customized the ksrvgen utility for Kerberos Version
4 which enables the security administrator to install Kerberos on
a new host. The utility should be converted to work with Version
5. Bellcore will supply the source code for ksrvgen.
1.5.2. Converting a Version 4 Database to Version 5
A utility which enables the conversion of a Version 4 database to
Version 5 will be required. Such a utility (kdb5_convert) is
included in the beta release from MIT, and should be tested by
enhancement providers.
1.6. Documentation
The Kerberos Version 5 beta distribution (dated September 30,
1992) from MIT is lacking in documentation. There are a handful
of manual pages which document the commands only, and not the
programmatic interfaces. The build and installation guides are
informal plain text files, thus a significant amount of work is
needed to document Kerberos sufficiently to support Bellcore and
Bellcore Client Companies.
1.6.1. Kerberos Installation Guide
An installation guide should be provided based on the
Installation Guide for Version 4 (as a starting point), adding
what is provided in the text files which came with the beta
distribution and other sources. Future work on improving the
installation process should lessen the effort to create an
installation document.
1.6.2. Kerberos Administration Guide
An administration guide should be provided based on the Operation
Guide for Version 4 (as a starting point), adding what is
provided in the text files which came with the beta distribution
from MIT. Aside from the manual pages already documenting the
commands to administer the Kerberos database locally, manual
pages need to be written for the remote administration server.
These include:
|----------------------------------------------------------------------|
|kadmin.1 |Kerberos V5 remote administration |
|----------------------------------------------------------------------|
|kadmind.8 |Kerberos V5 server for remote administration |
|----------------------------------------------------------------------|
|kpasswd.1 |change user's Kerberos V5 password |
|----------------------------------------------------------------------|
|ksrvutil.8 |manipulate V5 srvtab file |
|----------------------------------------------------------------------|
|ksrvgen.8 |generate a new V5 srvtab file |
|----------------------------------------------------------------------|
1.6.3. End Users' Guide
The end users' guide should be simple, since users of
``Kerberized'' programs should be shielded from the details of
how authentication is performed. The end users' guide should
refer to the correct procedure for changing the password.
1.6.4. Kerberos Implementors' Guide (GSSAPI Documentation)
We recommend that application developers use the GSSAPI (rather
than using raw Kerberos Version 5 functions). As such, there is a
need for providing documentation for the GSSAPI. There are
existing manual pages on the GSSAPI. However, they do not
identify the specific idiosyncrasies of its implementation over
Kerberos Version 5. This would involve describing the
interpretation of minor status codes (which are Kerberos-
specific), and updating the following manual pages:
|----------------------------------------------------------------------|
|GSS_display_name.3 |translate a GSS-format name to a printable format|
|----------------------------------------------------------------------|
|GSS_display_status.3|translate a Kerberos status code |
|----------------------------------------------------------------------|
|GSS_import_name.3 |convert a printable name to an internal name |
|----------------------------------------------------------------------|
|GSS_release_name.3 |free storage associated with an internal name |
|----------------------------------------------------------------------|
The information from the IETF draft RFC, which gives a detailed
explanation of the GSSAPI and its use, should also be
incorporated in the documentation.
In some cases, the GSSAPI may not be adequate. Users of the
programmatic interfaces (application developers) will need a
document describing the most important Kerberos functions and
giving examples of their use. There is a 44 page TeX document for
the programmatic interfaces which comes with the Kerberos Version
5 beta distribution. The implementors' guide should be based on
this document and should be enhanced to the level required by
application developers (UNIX style manual pages).
1.6.5. Utility Documentation
Kerberos administrators need adequate documentation for the
utilities described in Section 1.5.
1.7. Testing Activities
Testing will cover the advertised functionality of Kerberos.
There is no need to test the security of the Kerberos protocol,
since the protocol and its implementation have been tested for
weaknesses by many others in the security community, and we
assume that any such weaknesses have been corrected.
Test suites which exercise the Kerberos software in the following
areas, should be developed:
- testing the local Kerberos database manipulation routines,
- testing the Kerberos ticket server (krb5kdc) and the user
commands that access it (e.g., kinit),
- testing the functionality of a replicated (redundant)
Kerberos ticket server, including the case when a client
gets a ticket from the redundant Kerberos ticket server
while the master server is unavailable,
- testing the performance of Kerberos in a sample application
(sclient, sserver) that would request tickets at the rate of
two per second,
- testing the database propagation software (kprop, kpropd),
- evaluating the throughput of Kerberos in the case of a large
database (50,000 users),
- testing the remote database administration programs (e.g.,
kadmin, kpasswd), including functionality required by the
user in order to change a user's password in the Kerberos
database from a remote host,
- testing for error and failure conditions,
- testing inter-realm authentication by setting up two realms
and running the above tests,
- testing the utility to install Kerberos on a new host
(ksrvgen),
- testing the utility to convert a Version 4 database to
Version 5
2.0. SUBSEQUENT RELEASES - Proposed Enhancements
The following sections describe enhancements for subsequent
releases to supplement Kerberos software. Subsequent releases
should contain enhancements intended to make Kerberos more
reliable, maintainable, portable, and easier to administer. Any
enhancements which utilize Bellcore-developed services (such as
the enhanced error logging described below) should be made in a
modular way so as not to introduce any dependencies on these
services for potential Kerberos users who do not use these
Bellcore-developed services.
2.1. Communication Mechanism Modularity
Communication mechanism dependencies (on UDP sockets) are
currently spread throughout the entire code. These dependencies
should be isolated into separate header files and library.
2.2. Enhanced Error Logging
In order to make Kerberos easier to maintain and service, logging
calls should be added. Kerberos currently has error handling
routines which should be modified to log their output using
Bellcore-developed logging calls. The output may contain
parameter values, as required, to facilitate debugging. It is
expected that Bellcore will furnish, under license, the software
required to implement this. Mapping of error return codes to an
error message dictionary should also be implemented. This will
provide more detailed error descriptions. Additional logging
calls may be added in certain critical parts in the code.
2.3. Enhanced Configuration Maintenance Features
The main Kerberos configuration files (krb.conf and krb.realms)
must be kept in sync on all hosts. To accomplish this, a new
``Kerberized'' service should be defined that would manage this
database among the various hosts within a realm and across master
servers in other realms. Cached copies should exist on each host,
and periodic updates would be pushed to these hosts by the master
server. Inter-realm data should be exchanged between master
servers.
Interactive utilities should be created for the following
maintenance tasks:
- administering the configuration files (mentioned above),
- adding clients to a new Access Control List at the time
Kerberos is installed on a new host (via ksrvgen),
- controlling which application servers (e.g., rlogind, rshd,
telnetd) are installed and how they are configured.
2.4. Administrative User Interface
Kerberos currently comes with a command line user interface for
administration. This interface should be enhanced according to
users' experience with the initial release. A major enhancement
that should be provided is the addition of an X Window
System/Motif based user interface for administration. The user
interface will be used by the Kerberos administrator, as well as
by end users to change their passwords.
2.5. Documentation
Additional documentation would be necessary for the features
described above.
- Error logging routines and the error codes and messages
should be documented in manual pages.
- New installation documentation also must be provided to
support the new installation procedures.
- The new user interface should be documented.
3. Ongoing Activities
The following types of support should be provided for all
enhancement releases:
- Installation support for both initial installations and
subsequent releases.
- Consultation and support for application developers who are
incorporating Kerberos calls in their code.
- Support for run time problems at Kerberos installation
sites. The assumption is that the Kerberos server must be
available 24 hours a day, seven days a week.
- Code patches for bugs found in the Kerberos software.
Andre S. Cosma
andre@bae.bellcore.com
(908) 699-8441
RRC 1N-215
Steven J. Lunt
lunt@ctt.bellcore.com
(908) 699-4244
RRC 1L-213
Bellcore
444 Hoes Lane
Piscataway, NJ 08854
Date: Fri, 30 Oct 92 17:55:09 -0500
From: tytso@Athena.MIT.EDU (Theodore Ts'o)
To: Steve Lunt <lunt@ctt.bellcore.com>
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: Steve Lunt's message of Fri, 30 Oct 92 14:19:43 EST,
One comment which I would like to make:
I would like to urge all prospective vendors to consider making
enhancements to Kerberos freely redistributable, and not to make them
proprietary. Furthermore, I would also urge Bellcore to consider
including this as a requirement to their prospective vendors.
A short-term analysis might suggest that proprietary changes to
Kerberos would be (1) possibly cheaper to Bellcore and (2) more
profitable to the prospective vendor. However, Kerberos derives and
adds all of its value through being in a distributed environment.
Therfore, interoperability is extremely important --- which means that
open systems tend to be much more successful than proprietary ones.
X11 and the Free Software Foundation software suite stand as an
important examples of how making enhancements back so that _all_ may
benefit from said enhancements can be very successful. Cygnus Support
is wonderful example of a company which makes all or most of its
enhancements public, by feeding them back to the FSF, and yet has been
quite successful.
Kerberos is currently being distributed in the same fashion as
BSD and X11; it can be freely FTP'ed and used without any restrictions
(as long as MIT's copyright is not removed and MIT is not held liable).
We do not require that changes made to Kerberos must be sent back to us.
However, even if you do not feel bound by a moral obligation to make
improvements generally available (as sites such as Sandia National Labs
have graciously done), in the long run it would be to your and
everybody's benefit to do so.
- Ted