[OpenAFS] Re: foreign-realm members of system:administrators
have weakened powers?
Fri, 27 Jan 2006 15:03:30 -0500
On Friday, January 27, 2006 10:54:40 AM -0500 Ken Hornstein
> What do people think about the idea of having an AFS RPC which said,
> "Hey, what's your Kerberos realm?" This would have to be done
> unauthenticated of course, so I don't see it being any better from a
> security standpoint, but it would solve this particular problem, and it
> really makes more sense.
Well, it would be better than inferring it from dbserver hostnames, when
you get those hostnames from the DNS. It would _not_ be better when you
get the names from a CellServDB, if that comes from a trusted source. I
imagine that most sites use a mixture of CellServDB records from both
trusted and untrusted sources (I do not consider the GCO Public CellServDB
to be a trusted source, from a security standpoint, even though I maintain
My real concern with an approach such as you describe (which has been
suggested before) is that it would end up being blindly deployed in
situations where it is _not_ safe, which I suspect is a lot of them, and it
would encourage people to rely on "easier" insecure configurations even
when they have the ability to make it work right.
Security software that "just works" out of the box by defaulting to an
insecure configuration is not security software at all; it is
Moving forward with new authentication technologies that are in the works,
the cell-to-realm mapping issue is going to continue to be a problem. We
can take care of the issue of obtaining dbserver names from untrusted
sources, even if/when we adopt the use of per-server service keys.
However, we will still have to find a long-term solution to the
cell-to-realm problem. While the heuristic of doing host-to-realm mapping
on dbservers works for a large portion of deployments, it is actually
inconsistent with the model which GSSAPI and Kerberos libraries are likely
to support for domain-based service names, which would involve
"host"-to-realm mapping on the _cell_ name.
But design discussions for OpenAFS and the AFS protocols really belong in