[OpenAFS-devel] openafs - proposed cache security improvement

[Marcus Watts]

There are 2 interesting problems with the current
cache manager:
/1/ trusting data acquired with unauthenticated connections
/2/ trusting data in the cache acquired in different
security contexts.

The suid security advisory is a special case of this
problem, however the problem doesn't just pertain to
the suid bit or to unauthenticated access.  The real
problem is that the cache manager has no way to validate
that it is talking to the real server that is separate
from user tickets.

For user-space applications, such as pts, bos, vos, etc.,
this is not a problem.
This is really only a problem between
the cm & the bits it talks to, particularly:
	vl	- where volumes live
	fs	- everything else with files
	afsd	- the userland part of the cm
	n * <local users>

So the real problem is devising improvements to the security mechanism
used by the cache manager, fileserver, & vlserver.  In fact, this is
not so hard.  The existing universal mechanism, rxkad, provides for an
external ticket decoder.  rxk5 doesn't - but this is an easy fix.
An improved ticket can solve all our problems here.  All we need
is a special sort of ticket that the cache manager can use,
that can contain its own security information, plus an optional
regular user ticket.

The required security information is quite simple: all we need is
something that looks like a subset of a kerberos ticket, I'll call this
an "anonymous token".  Assuming our cache manager has its own secret
key, all this token has to have is a way to tell the file server what
that key is.  It won't have any identity information of its own,
because it doesn't need it.  For unauthenticated access then, this
token can work much like a regular kerberos ticket for rxkad/rxk5.
Since an identity makes no sense here, the file server (and vlserver)
will need to treat this much like a noauth connection.  IP acls could be
sensible here.  For authenticated access, the challenge will need to also
contain the user ticket, plus stuff that ties the user ticket to the
session key & the anonymous token.  User applications would not be
able to see the host secret key, only their own kerberos ticket, so
the cache manager now has a security context it doesn't have to share
with users.

So the largest problem left here is how exactly does the cache manager
acquire a "anonymous token", and what does it need to pass to the fileserver
so that the fileserver can derive a common shared secret?  This is the
classical key distribution problem.  Fortunately, since
identity doesn't matter much here, this isn't so hard.

desirable properties:
/1/ anonymous token should not have any persistant server side storage (not
in k5, not in vl, not on fileservers),
/2/ public key technology desirable for acquiring anonymous token.

The obvious approach for this anonymous token would be diffie-hellman
used straight, but this will cause ticket bloat issues if large prime
numbers need to be stuffed into rx challenges, also cpu load issues.
So, here's another way:

at cell configuration time:
	admin creates public & private RSA or DH key,
	advertises public key.
at cm installation time:
	local sysadm supplies public key for selected cells.
at cm startup (or some similar frequency):
	(in afsd userland),
	cm -> vl: use DH or RSA and private key for this cell
		to to setup secure connection
	cm -> vl to create a new "anonymous token".  pass nonce
		vl can create one this way:
			hmac(nonce, key-of-afs) = key
	vl -> cm
		pass key back to cm using shared secret
		from DH or whatever.
for ticket use,
	cm -> fs: pass nonce in anonymous token; expect afs server to
		compute shared key using hmac(nonce, key-of-afs)

The main remaining problem is that this expects some form
of public key cryptography to be accessible at runtime to
afsd, fileserver, & vlserver.  In the short-run, especially
for proof of concept, openssl is an obvious solution.  In the
long-run, openssl or bsd licensed code found somewhere are both
options.

				- Marcus