KDC proxy and delegation?

[Sam Hartman]

>>>>> "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
    Troy> network.

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.

--Sam