Auditing Feature in Kerberos

[K.G. Gokulavasan]

Hi,
1) We like to write an auditing layer where multiple auditing tools can
be plugged in.

2) Under the auditing layer, we will add Novell Audit and a module that
supports storing the audit data in a generic store. (described below)

3) For the generic audit store, we considered various options like XML
files, relational databases and Berkeley DB XML.

4) The advantages and disadvantages of each of them are:
    i) XML file - This is Standard, interoperable across systems and
human viewable format. But very slow and memory/space consuming.
   ii) Network database - The data can be queried using SQL. Even the
data can be retrieved in XML format. But this has issues like licensing,
network failure, storing the authentication data for database.
  iii) Berkeley DBXML - No licensing issue, can return query results in
XML format, runs with the KDC in same host. But this supports only BDB
as backend.

5) We recommend to use Berkeley DB XML.

6) Following are the data which are already logged in the file:
    Starting, stopping the services. TGT/TGS requests and Password
changes.

7) Following are the data to be audited in addition to the above:
    Service Tickets issued for a particular TGT, cross realm tickets -
hosts involved, ticket information 
   
   Please provide your thoughts/comments.

Regards,
 Gokul.


>>> Sam Hartman <hartmans at mit.edu> 1/25/06 2:26 AM >>>
>>>>> "Jeffrey" == Jeffrey Altman <jaltman at MIT.EDU> writes:

    Jeffrey> Sam Hartman wrote:
    >> I think that the big missing part of the current logging system
    >> that makes it hard to use for auditing is that it does not link
    >> service tickets that are issued by the TGS to the TGT used to
    >> issue them.
    >> 
    >> The other problem is that the format of the data cannot easily
    >> be parsed or stored in a database.
    >> 
    >> --Sam

    Jeffrey> Are you therefore looking to alter the existing log
    Jeffrey> format or to add a new interface that would allow for
    Jeffrey> direct to database writes of log data?

All of the following seem plausable:

1) a plugin interface for auditing

2) An additional XML log format (assuming limited additional
   dependencies; perhaps hand-generated xml)

3)  altered log format.

--Sam