A Critique of Kerberos and AFS

James F. Carter


At UCLA-Mathnet we use Sun's NIS for user authentication, and thus everyone's encrypted password is exposed to all users on local systems without a root exploit. For distributed file service we use Sun's NFS, whose access control is host-based and depends on user authentication on the client; thus it is insecure to export filesystems to machines not under our direct control, and spoofing exploits are not hard. Both protocols are not ideal when run through a firewall. We are therefore investigating alternative systems for authentication and distributed files. The conclusion is that Kerberos and AFS are the leading contenders.

1 User Authentication

What possibilities are there for authentication? I restrict the scope to only those that have PAM modules, since PAM is essential in Solaris and much preferred in Linux.

Of these authentication services, Radius and Kerberos are the major contenders. For Kerberos the tie-in with both Windows NT and Solaris is a big attraction, and also, AFS (if we choose to install it) requires Kerberos for access control. So let's look more closely at the advantages of Kerberos.

So what is wrong with Kerberos that might prevent us from using it?

I would conclude that Kerberos is likely to work; the transition to Kerberos is likely to be transparent for most but not all of our users; Kerberos will be much more secure than what we have; and we will get additional capabilities which may be very useful.

2 Distributed Filesystems

What are we looking for in a distributed filesystem? We want its access control to be hard to circumvent, and we want it to work through an aggressive firewall. It must be moderately scalable in the sense that we have 32 fileservers with 168 exported filesystems among them. Encrypting file content in transit would be nice but is not essential. Replicated readonly volumes for software (with transparent failover) would be a helpful addition. Also helpful would be sufficiently robust security that off-campus machines beyond our control could mount our filesystems with low risk to us. We must either have a dedicated Windows client or the data must be exportable via Samba.

In a web search I found a number of cluster filesystems. I don't think they're relevent here; their intended use is for high-performance parallel I/O, as in a Beowulf cluster, or for Storage Area Networks (i.e. fileserver appliances), or for enormous worldwide databases. I'm listing them here so in future searches they can be recognized and ignored.

There are, however, a few filesystems targeted at our kind of application.

Of these filesystems, NFS is the devil that we know, which all others have to measure up to. AFS is a strong contender, used at a number of sites to do what we're trying to do. Coda and DCE/DFS may or may not be contenders also, but our lack of familiarity with them puts risk in their columns. InterMezzo is for the future.

So if we replace NFS at all, we'll almost certainly replace it with AFS. What are its advantages?

AFS sounds like a really wonderful replacement for NFS, so why don't we, and everyone else, embrace it wholeheartedly?

3 Actions to Take

So what should we do now?