Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!eos!shelby!DOCKMASTER.NCSC.MIL!Riddick
From: Riddick@DOCKMASTER.NCSC.MIL
Newsgroups: comp.protocols.kerberos
Subject: Accounting Services, etc.
Message-ID: <900601121254.995253@DOCKMASTER.NCSC.MIL>
Date: 1 Jun 90 12:12:00 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 83


The latest set of messages on this mailing list brought up the issue of
accounting services for a network.  Specifically, if we have this great
authentication tool (i.e., Kerberos) then wouldn't it be a good idea to
use it to enable a network accounting service?

In fact, to enable a reliable and accurate accounting service on a
network, we need a mechanism to ensure the authenticity and integrity of
accounting data.  Currently, each vendor of a network service supplies
its own accounting tools for that service.  Network operating systems,
such as Netware and Lan Manager, provide some tools, but they do not
integrate completely with the applications and they do not employ
reliable authentication mechanisms.

What is needed is an Application Programmer Interface (API) with a set
of callable functions to an accounting service.  These functions would
enable the network service to submit accounting information to the
accounting server for incorporation into a centralized accounting
report.  The accouting server provides the repository for this data, and
it provides accounting reports to the network service suppliers.

The only flaw in this concept is the complete lack of security for the
accounting data as it flows from network service to accounting server.
THE THE SOLUTION:  Use an authentication mechanism (Kerberos) to
establish the identity of the service.  Provide mutual authentication so
that the service knows he is really talking to the accounting server.
Provide message integrity between the network service and the accounting
server.  Provide an API library that a vendor of a network service may
use to make calls to the accounting service.  This API library makes the
underlying authentication protocols transparent to the caller.

As an aid to understanding how authentication fits into this problem,
let me provide a way of looking at authentication of clients and servers
on a network.  In a network, there are two modes of authentication --
call them CONNECTION-ORIENTED and CONNECTIONLESS.  In
connection-oriented authentication, the client's workstation only
presents a service ticket to the service at the initial contact for
service.  Subsequent message exchanges with the service do not include
the ticket.  The service authorization is valid as long as the client
remains logged on to the network and the ticket remains active.  In
connectionless authentication, an authenticator must be supplied with
every service request packet or message between the client and the
service.

In connection-oriented mode, it is assumed that protection of the
communications between the service and the workstation are not at risk
of compromise.  The connectionless mode ensures that the server
authenticates every request from the client so that the threat of
workstation masquerading is minimized.  The connectionless mode does
incur more overhead than connection-oriented mode.  Kerberos can be
classified as a connection-oriented authentication protocol.

All of these services should be based upon Remote Procedure Call (RPC)
mechanisms rather than direct communications interfaces to ensure that
they are accessible across dissimilar hardware and operating system
environments environments.  The OSF has announced their selection of a
Distributed Computing Environment which includes Kerberos and an
enhanced Apollo RPC mechanism.  AT&T/UI is also forming their own DCE.
Either one would serve as the platform for developing the accounting
service in question.

Finally, I would like to mention that my company is developing a product
that conforms to the Kerberos protocols and provides some of the
services mentioned.  Also, I have been trying to port the V5 release of
Kerberos over to a 386 machine running SCO UNIX.  The problems I have
encountered so far have been with the 'cpp' on my system stripping TABS
from the Makefiles forcing me to manually adjust those files.  Also, I
have yet to get past the makedepend build due to compiler errors in the
source files.  Specifically, there are a lot of BSD specific usages,
including the use of symbolic links.  Are symbolic links used througout
the code, or can I safely remove the checks for symbolic links?

Anyone interested in discussing any of these issues can contact me via
email:

          Riddick.Catwalk -at DOCKMASTER.NCSC.MIL

phone:  (703) 758-0190

address:  Chris Riddick
          Simpact Associates, Inc.
          12007 Sunrise Valley Drive
          Reston, VA  22091