[OpenAFS] afs authentication

[Christopher A. Petro]

I recall being pretty impressed with AFS authentication back in 1993.  It
doesn't seem quite as spiffy anymore, though.  The last few messages about
a 3DES key breaking it and my own recent hassles have got me thinking about
it quite a bit.  Now that I have AFS up and running on my machines (except
for XP where the client just flat out refuses to start, though it can
authenticate just fine), I'm thinking about doing something about it.

I see two real problems with the current authentication:

 * It's DES.  I can capture any two packets in a row from the client/AS
   handshake and brute-force the password hash in no time.  That's all
   I would need to get in using a modified klog, and getting the actual
   password from it wouldn't be difficult either.  I love the following
   bit from the Authentication Server Spec: "It is implicitly assumed
   that anyone prepared to do a serious cryptographic attack on DES
   encrypted data in this system can have whatever he or she can get.
   Any data so sensitive that this might be a problem should be subject
   to additonal safety measures.  No such data should be stored in the
   Andrew File System."  I don't know about you, but I think my _spam_
   deserves more protection than DES. :)

 * It's password-based.  A lot boredom.org users log on from untrusted
   machines such as .edu lab machines, public clusters, etc. where they
   have to assume that there's a keysniffer running.  In the past we have
   always solved this using S/KEY.  For now some of these people are using
   S/KEY to auth to one of the client machines and then having their
   login script klog them into AFS using a plaintext password stored
   on the local file system.  Clearly suboptimal.

The beauty of access being controlled by opaque tickets is that it
should be very, very easy to replace the initial authentication without
having to make modifications to parts of the code not related to
authentication.  Assuming the code related to verifying tickets is nicely
tucked away in a library and the tickets are handled opaquely everywhere
else, strengthening the protection on tickets should also be relatively
trivial.

Obviously I'm making a lot of assumptions about the code without having
really read it.  Before I start a project like this, is anyone else working
on improving the authentication in the system?  Am I incorrect in assuming
that the authentication code is well segregated and modular?  The original
AFS documentation all makes it sound like the system was designed to be
fairly agnostic about how this all worked internally, going as far to say
that any secret key-based encryption would be fine to use, so I don't
foresee any changes to authentication violating any fundamental design
principals.

Clearly the changes should be backwards-compatible.  If a cell doesn't
allow particular users to authenticate using DES, attempts to log in
using and old client making the original RPC calls should fail auth
gracefully.  What other concerns might there be?

Comments and thoughts are greatly appreciated.