Auditing Feature in Kerberos
jhutz at cmu.edu
Tue Apr 4 11:38:57 EDT 2006
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
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev