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