KDC proxy and delegation? (was discussions about AFS service tickets)
hozer at hozed.org
Sun Jan 21 17:27:35 EST 2007
> Jeffrey> * Service A authenticates as service A to service B
> Jeffrey> where the two services share the same key
> Especially for things that really need to work when the KDC is down,
> this seems ugly but perhaps necessary.
> Jeffrey> * Service A authenticates as authenticated user U to
> Jeffrey> service B where Service A is trusted to do so. (Think
> Jeffrey> Samba or WebDAV export of AFS without credential
> Jeffrey> delegation of the client's credentials.)
> This case really needs to involve the KDC for auditing and
> It's because of this case that I'm very nervous about providing this
> functionality. If we could find a way of providing the functionality
> for AFS, but making it very clear that it was not generally useful and
> that designing applications to depend on it is a bad ide, I'd be much
> Jeffrey> This provides a benefit to services that rely on the
> Jeffrey> Kerberos 5 ticket format as an internal authentication
> Jeffrey> token format.
> I'm not convinced services should do that unless they use the Kerberos
> Jeffrey> Without krb5_generate_creds_with_keytab there are two
> Jeffrey> alternatives that AFS can pursue:
> Jeffrey> (1) AFS can use the keytab entry to query the KDC for a
> Jeffrey> ticket for itself. Doing so removes the ability of
> Jeffrey> multiple AFS services on the same machine to communicate
> Jeffrey> when the network connection goes down unless there is a
> Jeffrey> KDC instance on the machine.
> I think that this is a far better design for AFS.o
There was a whole bunch of detailed discussion about this, but it seems
the fundamental issue is how to design a service which depends heavily
on kerberos authentication, and *requires* it for local administrative
tasks, and how to make this set of services work when the KDC is
My first thought was "why *not* run a KDC locally".. maybe what we
should really be doing long-term is developing mechanisms to support
distributed KDC's, or at least allow proxying and delegation of specific
keys to a sub-KDC which in the AFS case would be run on every AFS
server, and would have a switch that could be flipped to allow 'local'
auth only and allow authentication (but no updates to keys) for
maintenance of when a machine is disconnected from the network.
Since any local-auth only solution is going to depend on the OS kernel
for enforcement of process isolation anyway, It would be natural to me
that this KDC proxy/delegate code would be running in protected kernel
space, and part of the fundamental OS-level security infrastructure.
My second thought while writing this was that maybe the natural solution
to this problem is cross-realm trust, where every $SERVICE server has a
minimal KDC that can be configured to trust the main realm KDC, and only
functions to authenticate services on the local machine to each other. I
could continue to get into disturbing ideas like using a reconfigureable
computing hardware accelerator as the local minimal KDC, but that would
be far beyond the scope of this list ;)
Are any of these ideas doable? They seem much cleaner to me conceptually
than messing around with special APIs to forge service tickets, and
would remove much of the schizophrenia I experienced when I first
configured an AFS cell and didn't really know what the difference
between authenticated access and -localauth was.
More information about the krbdev