[OpenAFS] why kerberos only works in monolithic organizations

[Ken Hornstein]

>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.

Can they?

How do they verify a certificate if they don't have some sort of trust
relationship with a realm?  I need to somehow securely get ahold of
a CA certificate to verify a junk certificate.  So if I'm an application
server (using the Kerberos parlance), I still need to be told about
the the CA certificate in some secure manner ... just like in Kerberos
I need to be given a service key in a secure manner.  In theory you don't
need to encrypt the CA certificate, but you should verify it's integrity
somehow.  This is one of the places where PKI tends to cheat; it works
great in the usual case where web browsers have a standard list of
CAs that they accept.

>> 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.

While I agree it removes the need to share a _secret_, they still need
to have some sort of trust relationship that should in theory involve
some out-of-band initialization.  At the end of the day, I don't see
this fundamentally easier than the initialization that Kerberos does.

The one big advantage with public key crypto in this case is that
if the application server's CA list is discovered, there is no
security vulnerability introduced.  If an application server's Kerberos
service key is discovered, that's a big problem.  But that doesn't
change the _management_ cost in the general case.

>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.

(Technically, it's ((N - 1) ^ 2) * 2, but it's still O(N^2), so I suppose
that's quibbling).

Well ... as a KDC admin, I'm not sure I want to let any random realm
out there authenticate with my realm without doing some sort of
validation.  I could see a case where two different people could claim
to be UNLV.EDU (someone could purchase a certificate from an
unscrupulous CA), and I want to be sure that the "right" one is the one
I accept.  I would suspect that most KDC admins feel the same.  One
purpose the cross-realm authentication process serves right now is
checking that.

Now, the actual _crypto_ part of that sucks (having done it too many
times).  There are a couple of ways to alleviate that pain.  One is
transitive cross-realm; I've used that in practice, and that works well
(you have to transit multiple realms instead of each one directly).
Instead of having to key each pair directly, I have to edit a config
file and say, "this path is valid".

As other people have mentioned, PKCROSS is an option.  The various
people in the Kerberos community all think it's a reasonable idea, so
it's not politically contentous.  All it needs is someone with the will
to do the actual work (from a standards point of view, and the actual
bit fiddling).

--Ken