KDC proxy and delegation? (was discussions about AFS service tickets)

[Troy Benjegerdes]

>     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
> authorization.
> 
> 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
> happier.
> 
> 
>     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
> protocol.
> 
>     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
inaccessible.

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.