Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!apple!agate!darkstar!saturn.ucsc.edu!keller
From: keller@saturn.ucsc.edu (Jeffrey M. Keller)
Newsgroups: comp.protocols.kerberos
Subject: Re: Accounting Services, etc.
Summary: accounting for kerberized services and clients
Keywords: kerberos, accounting, services, daydreams
Message-ID: <4007@darkstar.ucsc.edu>
Date: 2 Jun 90 01:25:17 GMT
References: <900601121254.995253@DOCKMASTER.NCSC.MIL>
Sender: usenet@darkstar.ucsc.edu
Organization: University of California, Santa Cruz
Lines: 60


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.