Auditing Feature in Kerberos

[Jeffrey Hutzelman]

On Tuesday, April 04, 2006 06:49:16 AM -0400 "K.G. Gokulavasan" 
<kgokulavasan at novell.com> wrote:

>   The scenario where auth_time + principal_name won't be sufficient to
> link TGT with TGS will be the same principal having requested for 2 TGTs
> at the same time. Either the request can be from the same host or
> different hosts. Adding client host address to auth_time +
> principal_name will help in linking the TGT with TGS when the requests
> are from different hosts. So the left out one is the same principal
> requesting for 2 TGTs at the same time from the same host. I feel this
> is not a common scenario and auth_time + principal_name +
> client_host_address should be sufficient.


Well, there are a couple of problems with that...

First, I don't believe your claim that it is uncommon for the same 
principal to request 2 TGT's at the same time from the same host.  Maybe 
this would be a reasonable assumption if you were tracking auth time with 
finer granularity than one second, but I wouldn't count on it.  And you 
can't have the KDC guarantee that the auth times will always be different 
both because a maximum rate of 1 request per second is too low and because 
there might be multiple KDC's.

Second, with addressless tickets there is no indicator in the ticket of 
what client host it was issued for.  You can't make the assumption that the 
ticket was issued to the same host that is now making a TGS request, 
because with addressless tickets users can and sometimes do move 
credentials between machines (not very often, we hope, but it can happen).

Third, IP addresses are locators, not identifiers.  Users can and do pick 
up entire hosts with valid tickets and move them to different places on the 
network.  And with NAT's, multiple hosts may appear to you to have the same 
IP address.  You can't differentiate them by port, because in the common 
case, the AS and later TGS exchanges are performed by different programs 
using different source ports.  So, you cannot depend on the source IP 
address of a request to uniquely identify the host making the request.



Finally, audit logs are about being able to prove that something happened, 
or in some cases, that it didn't happen.  That means it's generally not 
good enough to be able to say "well, if you make all these hand-wavy 
assumptions, then this is probably what happened".  You need to be able to 
say "if the audit log hasn't been tampered with, this _is_ what happened, 
and these are the steps we've taken to ensure the log can't be tampered 
with without it being noticed".

If you want to be able to tie a chain of AS and TGS requests together, it 
seems fairly straightforward to do this by recording a hash of the TGT on 
each transaction.  You don't have to depend on fields the client may have 
tampered with or lied about, or that have to be carefully managed to ensure 
they are never the same in two TGT's even when issued by different KDC's. 
The hash is easy to compute on each transaction; in fact, since Kerberos 
tickets are encrypted and integrity-protected, you're already doing more 
work encoding and decoding the ticket than would be required to compute a 
suitable hash.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA