>> I also would like something more scalable than CellServDB (the /etc/hosts
>> file of the future). Keep in mind however, that this file determines
>> where the Cache Mgr goes for authentication information. Compromising
>> that information could cause some security problems.
> are you saying afs doesn't do mutual authentication?
I'm saying that the client machine itself can't verify whether the
authentication server on the other end of the "connection" is the
authoritative server for a realm. To authenticate the server it
needs to anchor its decision against something -- either a secret
only it (and a trusted third party) possesses or a secure path to
some higher authority. Otherwise a Bad User could trick a client
machine into listenting to a Bad Kerberos server which would
provide a ticket sealed under a key that the Bad User knew.
Right now AFS "secures" this path by keeping the IP address of the
authentication server local to the machine. Unfortunately, IP routing
is only relatively secure, so even this isn't real good. But adding in
a DNS lookup is only going to make it worse.
For AFS, the above isn't a huge problem because the service being
secured is delivered from servers which only grant particular access
to users authenticated within the cell in which the servers reside.
Note that the file servers do have a local secret (/usr/afs/etc/KeyFile)
by which they can authenticate the Kerberos ticket and that their
local CellServDB is presumably securely maintained. Thus you can't
get useful service from the server unless you present it with credentials
valid to an authentication manager it can verify. Other services
also need to do this. If the "service" you are trying secure is
access to the client workstation, then you need to have a local
secret on the client workstation...
While I haven't looked at it in depth, what I've heard is that DCE
clients anchor their client machine access decisions against a local
secret.
Bill
