> are you saying that afsd does not engage in mutual authentication
> with its principal service providers?

No. What I'm saying is that Kerberos relies on the authenticating
parties trusting a 3rd party server. To do so, they must know the
address of that server, which is held in a local file (we assume that
local file systems can be trusted). In the case of AFS, that file is
CellServDB; vanilla Kerberos uses /etc/krb.realms.

Putting this info in a distributed service like DNS means that a
cracker's machine can potentially masquerade as the trusted third party
by intercepting requests to the distributed CellServDB, and convince
the AFS client and server that it is genuine; UNLESS the distributed
service is also authenticated via a REAL third party to both client and
server. This is possible, but not widely used (certainly not by DNS) -
and requires cross-realm authentication if one cell is to trust
another, so that any sites wishing to join in must exchange keys (out
of band) with all other sites, and maintain a list of all other
Kerberos servers. Much like we do now with static copies of CellServDB!

The real solution is distributed hierarchical authentication, the pros
and cons of which are not for discussion here. It's worth noting that
this is effectively what the AFS community does, i.e. we trust Transarc
to give us the correct information by copying their authoritative
CellServDB, and Transarc trusts us to give the correct details of our
sites, rather than every site having to trust every other site ad hoc.
We don't exchange keys out-of-band, though.

I agree with the Brian Fitzgerald's sentiment; a distributed database
is required. I merely point out that this problem is generic to
Kerberos, and has yet to be satisfactorily solved.

Peter Lister                                    [EMAIL PROTECTED]
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

Reply via email to