[OpenAFS] my afs wish list

[Marcus Watts]

Derrick J Brashear <shadow@dementia.org> sent:
> On Mon, 28 Apr 2003, Marcus Watts wrote:
> 
> > Well, I'm certainly not wedded to rxkad per se.  One of the nice
> > things about rx is that it does have hooks for other schemes.
> >
> > But rxkad looks a lot cleaner to me than a lot of rx has gotten.
> > There's a whole messy piece of rx that's devoted to trying to "solve"
> > the mtu problem, which it can't because (a) it doesn't get icmp
> > "don't frag" errors, and (b) it deals with "packets" not "bytes"
> > so the windowing unit is inherently flawed.
> 
> But the problem is the concept of rxkad "levels" loses meaning if you try
> to extend them. Like, a mechanism that provides stronger integrity than
> what we have now, but no encryption, will necessarily be a higher level
> than rxkad_crypt. How do you do ordering? How do you do a minimum?
> 
> For that matter, how do you do the security exchange?

Seems to me that rxkad "levels" are orthogonal to encryption type.  I
think they're a nice idea, and that it doesn't hurt to support having
authentication and integrity checking without necessarily paying the
overhead for privacy too.

I don't think I'd want to confuse this at all with encryption type.
Doing the security exchange seems simple.  I'd let the KDC deal with
it.  If client code gets a KDC ticket that has an AES session key in
it, then it should do AES.  If client code sees a KDC ticket that has
DES in it, it should do DES.  Client code that only understands DES
should just give up when it sees an AES key.  The only place where this
gets at all potentially confusing is the server, which for migration at
least ought to be able to swallow both DES and AES.  During the
migration period, new client code ought to use AES while old client
code uses DES, and a particular user's session should still be all
AES/all DES.  I'd sure hate to see "dual" AES/DES tokens
floating around in anybody's cache manager.

Like I said, I'm not wedded to rxkad.  I remember originally thinking
that the blocksize / DES logic looked pretty tightly wedded to the
protocol, and deciding it made more sense to just replace rxkad.  Since
then I see some people have had luck teaching rxkad about k5, which
makes using rxkad more tempting, but not necessarily practical.  So I
don't see a problem with just "replacing it".  Actually, the biggest
thing that stopped me was what to name a replacement.  "rxkad" has a
nice ring to it.  "rxrc6" or "rxaes" or "rxk5ad" don't seem nearly as
pronounceable to me.  Ok, so this is a silly thing to worry about.

Jon Bendtsen <jon+openafs@silicide.dk> writes:
> Why just encrypt the data streams? Actualy i think that encrypting the
> datastreams might not be the best option, since it would introduce extra
> encryption/decryption, costing cputime. My suggestion is to store the
> files (encrypted) on the server, but to the server, they are just 
> another file with a strange name. (sort of like cryptfs does). Then you
> would let the klient do the en/de-crypting. The client probably has alot
> more cpu power than the server, especialy if the server has to serve 
> 23089233489723734 clients (or there about).

Encrypting files on the server doesn't help you to individually encrypt
it for each user.  If a given file is encrypted under one key for all
users, then you get nasty problems.  With symmetric encryption, if you can
decrypt something, then you can also encrypt your own stuff using the same key.
Perhaps you would like to use assymetric encryption - but that has its own
problems in terms of slowness and &etc.  If you can describe and solve all
the problems, it could make for an interesting paper.  But I think you face
some formidable problems in terms of key management and all.  You will
definitely end up with completely different client and server code than AFS
if you do this.

Anyways, rx provides data streams, and xdr layers on top of that.
There isn't a separate "streaming" layer - rx does it all.  The
security layer in rx (aka "rxkad") is the only guy who has to worry
about how to make the encryption stuff work - since that lawyer doesn't
currently see file transfers as anything special, only encrypting "file
transfers" actually makes this a harder project.

Dean Anderson <dean@av8.com> writes:
> You mean something like "rxblowfishd" (the ka means kerberos
> authentication, right...)  I was looking at the RX spec last week. It
> seems that there are hooks just for this. Unfortunatly, there seem to be
> some hints in the rest of the afs code that use rkaxd specific headers and
> functions.

Oh, there's plenty of ugliness in the AFS headers and libraries.
But cleaning up that up is a trivial matter; it's just pain.
(granted, a *big* pain -- would be nice to see shared libraries
come out of this too.)

blowfish has truely excessive key setup time and is a 64-bit block
algorithm.  It is clearly designed for protocols where keys can be
setup once and used for a single long coversation.  With RPC, you have
much shorter chunks that get encrypted, and with K5, you generally also
have key usage which means you make trivial permutations of the same
key for different uses.  These both break the blowfish assumption.
Anyways, the long key setup time in blowfish is there mainly to slow
down brute force key searches.  A better way to do this is to have a
really big key search space, like 128 or 256 bits, then you don't need
an expensive key setup.

So instead of blowfish, you have twofish; 128-bit blocksize, big keys,
and fast key setup; much more attractive than blowfish.  You also have
rijndael, serpent, cast-256, and a variety of more proprietary
algorithms such as mars, rc6, etc., all of which were candidates for
AES so have similar characteristics.  Since rijndael is fairly fast and
going to be part of K5 anyways, this would seem to be particularly
attractive.  Twofish could work too in place of rijndael - but there's
no clear advantage and I think it makes sense to do one rather than
doing 2 or 3 and having more code to break.

					-Marcus Watts
					UM ITCS Umich Systems Group