KDC proxy and delegation?
hartmans at MIT.EDU
Sun Jan 21 17:48:03 EST 2007
>>>>> "Troy" == Troy Benjegerdes <hozer at hozed.org> writes:
Troy> There was a whole bunch of detailed discussion about this,
Troy> but it seems the fundamental issue is how to design a
Troy> service which depends heavily on kerberos authentication,
Troy> and *requires* it for local administrative tasks, and how to
Troy> make this set of services work when the KDC is inaccessible.
Troy> My first thought was "why *not* run a KDC locally".. maybe
Troy> what we should really be doing long-term is developing
Troy> mechanisms to support distributed KDC's, or at least allow
Troy> proxying and delegation of specific keys to a sub-KDC which
Troy> in the AFS case would be run on every AFS server, and would
Troy> have a switch that could be flipped to allow 'local' auth
Troy> only and allow authentication (but no updates to keys) for
Troy> maintenance of when a machine is disconnected from the
I think this is a fine approach to consider.
Troy> Since any local-auth only solution is going to depend on the
Troy> OS kernel for enforcement of process isolation anyway, It
Troy> would be natural to me that this KDC proxy/delegate code
Troy> would be running in protected kernel space, and part of the
Troy> fundamental OS-level security infrastructure.
I disagree you want the KDC running in the kernel, but I agree it
needs to be part of the TCB of the local machine.
Troy> My second thought while writing this was that maybe the
Troy> natural solution to this problem is cross-realm trust, where
Troy> every $SERVICE server has a minimal KDC that can be
Troy> configured to trust the main realm KDC, and only functions
Troy> to authenticate services on the local machine to each
Troy> other. I could continue to get into disturbing ideas like
Troy> using a reconfigureable computing hardware accelerator as
Troy> the local minimal KDC, but that would be far beyond the
Again, I believe this is a reasonable approach.
I think your ideas are great, but they are kind of long-term. I think
the API Jeff and I agreed to is consistent with them though, if you
accept that access to a certain keytab can be used as a local
capability for the ability to force authentication.
More information about the krbdev