Riddick@DOCKMASTER.NCSC.MIL (06/01/90)
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 22091keller@saturn.ucsc.edu (Jeffrey M. Keller) (06/02/90)
Well, i was feeling fanciful, and nobody had given an authoritative
description of how to do authenticated service accounting, so i thought
i'd try to construct a model for it.
Accounting Server ("The Bank"). Maintains a database of accounts.
Each record contains (at least) the following information:
Account ID
Balance
Authorized users
Usage restrictions
History (i.e. a record of events)
Purchase Order ("PO"). This is a kerberos ticket issued by the
Accounting Server at the request of an Authorized User. It contains:
Client ID
Server ID
Service in question
Bank ID
Account ID
Maximum value
Expiration date (Well, any kerberos ticket has this, but here
it's important.)
This ticket guarantees the availability of sufficient funds until such
time as it either expires or is redeemed. It is useful when the cost
of a service (or a reasonable bound) is known and the server can be
trusted not to engage in petty larceny. Note that issuance of a Purchase
Order may be denied if the service in question does not satisfy the
usage restrictions of the account. If the client presents the PO to
the server specified on the PO, the server may then present it to the
Bank, specifying what portion of the PO was actually used. The Bank
then updates its database and, regardless of how much of the PO was
actually used, records it as being void. (It keeps the PO on the void
list at least until its expiration date has passed.)
Contract Mediator. This is server (possibly the same as the Bank),
for mediation of transactions where the client and server do not trust
each other. For the Mediator to be useful, it must be trusted by all
parties involved, and it must be able to determine whether or not the
service in question has been faithfully performed. (For some
purposes, either verification of performance or verification of
non-performance might suffice.) The details of its operation would
depend on what was negotiated, and could be arbitrarily specialized
and elaborate.
I think the accounting service and the purchase orders would work
quite nicely for conventional computer accounting needs. It could cover
accounting for CPU time either by the introduction of compute servers,
or by having the machine in use fetch purchase orders for itself as
necessary. (Presumably, you trust the machine you're using.) I'm
not certain that the Mediator would be both valuable and feasible.
So, what do people think -- is it useful? flawed? already been done?
--
Jeff Keller keller@saturn.ucsc.edu (408)425-5416
THIS LIFE IS A TEST. IT IS ONLY A TEST. HAD THIS BEEN A REAL LIFE,
YOU WOULD HAVE BEEN GIVEN INSTRUCTIONS ON WHERE TO GO AND WHAT TO DO.bcn@CS.WASHINGTON.EDU (Clifford Neuman) (06/02/90)
I have put considerable thought into how to properly handle both authorization and accounting through Kerberos. The authorization data field in version 5 of Kerberos allows these functions to be easily supported. I have been working on a paper that outlines my approach, but that paper has been temporarily on hold. If people keep after me, I will polish it off. The abstract follows. ~ Cliff --- Authentication Based Authorization and Accounting In recent years there has been much interest in secure authentication of principals across computer networks. There was been less discussion of distributed mechanism to support authorization and accounting. These problems are much closer to authentication than most people realize. By generalizing the authentication model to support restricted proxies, both authorization and accounting can be easily supported. This paper shows how to support restricted proxies in an authentication system, presents the appropriate model for authorization and accounting, and describes how they may be easily implemented on top of authentication.
pato@APOLLO.COM (Joe Pato) (06/05/90)
The recently announced OSF DCE includes an authorization service that uses
Kerberos V5 as the authentication engine. Objects (files, entries in the name
system, entries in the authentication/authorization database) are protected by
access control lists (ACLs) and principal privileges/identity appear in
privilege attribute certificates (PACs). PACs are sealed in the authorization
data field of a V5 ticket.
System specifications from the OSF are forthcoming.
-- Joe Pato
Cooperative Object Computing Operation
Hewlett-Packard Company
pato@apollo.hp.com
-------