[OpenAFS] why kerberos only works in monolithic organizations

Douglas E. Engert deengert@anl.gov
Fri, 30 Dec 2005 09:12:56 -0600

Adam Megacz wrote:

> Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
>>Maybe it's me, but I've never really seen the difference between a junk
>>certificate and a Kerberos ticket;
> Somebody with no prior trust relationship can check the validity of a
> junk certificate.

Not nessesarily. Only if the CA certificate used to sign the "junk
certificate" is trusted in some way. kx509 can could be setup to use
a self-signed CA certificate or a CA certificate signed by some higher
level CA. In either case there is some trust relationship be it specific
or implied.

>>I'm confused; do you know about some cryptosystem that I don't that
>>doesn't require users to know some sort of key?
> Asymmetric cryptography eliminates the need for the party verifying
> the key to share a secret with the certificate issuer.
> This is the problem with Kerberos when you try to expand beyond a
> single administrative domain (or more than a few for whom it is
> feasible to do N^2 cross-realm): you have to hunt down the KDC admin
> and cajole him/her into doing you a favor.

And this is where PKINIT may play a much bigger roll. The "cross trust"
is done at the PKI level, and certificates are enrolled in the local realm
as needed.

We may see this when the HSPD-12, NIST PIV smartcards start being used
across the federal government. If implemented correctly, the agency CAs
should be trusted by other agencies using the federal bridge CA.

This may complicate the client side, as the client may have to have
Kerberos tickets from multiple sites that don't do Kerberos cross realm
but do trust the user's certificate.

> This works fine for a certain set of organizations, which, as a
> result, have been the only ones who use Kerberos (and hence AFS for
> the most part).
> Kerberos was designed in an era when computers were much slower and
> the (much greater) computational burden of asymmetric cryptography was
> a serious problem.  This is no longer the case.
>   - a


  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444