[OpenAFS] AES Support ?

Marcus Watts mdw@spam.ifs.umich.edu
Wed, 26 Sep 2007 05:46:35 -0400

> Date:    Wed, 26 Sep 2007 09:18:21 +0200
> To:      openafs-info@openafs.org
> From:    "Johan Pellkvist" <pellkvist@gmail.com>
> Subject: [OpenAFS] AES Support ?
> I have been looking for some information for a while, any help would be
> appreciated!
> Is it still required to use des-cbc keys ?
> Will there be a version that support AES keys/encryption in the near future
> ?
>  Anybody know the status of this, work in progress ?
> If it is already possible to configure OpenAFS this way, maybe someone
> please can point me
> to a howto/tutorial or similar...
> Thank you
> /jope

There has been work on this, but it's very definitely a "work in progress"
and not something that comes in a distribution that you can just
turn on & forget by following a tutorial.

So that you know, the current standard security mechanism in OpenAFS,
rxkad, is pretty hopelessly dependent on 56-bit keys and cannot be
transparently upgraded to AES.  So, the plan is to replace rxkad with
another security mechanism layered on top of kerberos 5.  There are 2
such mechanisms coming down the pipe that will do this, rxk5, which offers
essentially the cryptography present in kerberos 5, and rxgk, which uses
gssapi & will feature its own separate list of cryptographic systems.
(Both will certainly support AES.)  Of the two, rxk5 is substantially
simplier and closer to being ready to deploy, so is likely to reach you first.

As of this writing, experimental patches for rxk5 exist for "cvs head"
and openafs 1.5.{various}.  Various versions of this have worked
on i386, amd64, windows, and aix, and portions have worked on
sparcv9/solaris.  There is still a certain amount of "polishing"
that needs to be done.

When rxk5 reaches you, it will almost certainly have this property:
you will need to upgrade all your server machines to support rxk5.
Having done so, you will then be able to support both rxk5 client
machines as well as rxkad client machines.  rxk5 client machines will
also be capable of accessing other cells using rxkad.  After you turn
off your last rxkad-only client, you could choose to retire the rxkad
service key & only support rxk5 to your local cell.  You can of
course also deploy rxk5 server software before turning on rxk5 in your
cell.  What makes your cell "rxk5" capable is if you have an
"afs-k5@YOUR-REALM" service key.  There will probably be some vaguely
squirrely issues about the exact version of kerberos you have installed on
client machines for some platforms, particularly for vendor binary-only
libraries.  rxk5 includes support for des/des3/rc4/aes, however, it is
likely most rxk5 cache managers will not do des (for rxk5).  In order
to run rxk5, you will need a kerberos 5 kdc - kaserver won't do.

If you adopt rxk5 early, you will probably find it useful to set up
a separate test cell to experiment with rxk5 -- particularly to catch
any local client kerberos library compatibility issues.  This should
not be any big deal; you can learn a lot with a pair of cast-off
Dell workstations which should take you no more than a day to setup.

So, the things you can do now to be rxk5 ready are:
 /1/ switch from kaserver to heimdal or mit kerberos 5.
 /2/ make sure you can upgrade *all* your fileservers & db servers.
 /3/ keep some "old" servers around with which to experiment.

				-Marcus Watts