[OpenAFS] Supported enctypes in OpenAFS 1.4.x

[Marcus Watts]

I should say some further stuff that might help people for
planning purposes.

The rxk5 openafs service principal name is:
	afs-k5/<cell-name>@realm-name
when you create this principal, you tell the kdc what encryption
types are to be supported - you should not list any types your server
binaries cannot handle.
You'll then save that on your openafs db servers in some keytab like
	/etc/openafs/server/keytab.afs
and this file will replace "KeyFile" for rxk5.  Whether you support
rxkad or rxk5 on your servers depends entirely on if you have a keyfile
or keytab.  If you have both, you'll support both.  If you create
an "afs" principal with other than des key types, you lose.
Migrating your servers to rxk5 consists of upgrading your software
and installing the keytab.  You might need to fiddle with krb5.conf
or /etc/openafs/server/krb.conf, depending.

When you run aklog, it will query the local cache manager to see
what types it supports, intersect that against the kerberos libraries
aklog was linked against, then give that to the kdc will will
intersect that against the key types it has and supports and select
the "best one", which will probably be the first one that aklog gives
it.  If you run an rxk5 enabled aklog, it will get and store an rxk5
credential by default unless you indicate by command line flag (-k4) or
environment variable to save an rxkad token.  You can be authenticated
in multiple cells, and whether the cm uses rxkad or rxk5 to a particular
cell (for a particular pag) will be determined entirely by which kind of
token was last set for that cell (in that pag).

When you run other tools, you will have the opportunity to tell
it both the cell & some clue as to which credentials cache to use
via command line arguments.  You will be able to point to either the
keytab (rxk5 localauth), the keyfile (rxkad localauth), a kerberos 5
credentials cache (rxk5), a ktc token (rxkad or rxk5), or nothing
(noauth).  Again, you'll be able to use rxk5 in one cell or rxkad in
another, using the same tool.  There are some intelligent defaults here
so if you tell it "-localauth" it will see if you have a keytab first,
then try for the keyfile.  This part is the last thing left to finish -
so I won't tell you the hackish flags Matt and I used in
development.  With aklog, you were able to use "-k" if you didn't
have the domain_realm stanza right in your krb5.conf file.  With the
other tools, this capability likely won't be there, so plan on
fixing krb5.conf so that you don't need to use -k even with aklog.

So far as tools goes: we don't plan to do anything with kaserver.  An
rxk5 version of kaserver just doesn't make sense without also making it
a k5 kdc, and there are lots of perfectly good krb5kdc's already.  For
ptserver, we use just the current name structure, with the obvious
s/\./\// hack.  Other people are working on teaching ptserver about
multiple name spaces, so we hope in the future that will provide a
native k5 name space for rkx5.  bos/vos/pts are the 3 big userland
tools, and all those work with rxk5.

The actual wire data packet encryption or integrity checking is done
using standard kerberos 5 algorithms - what your kerberos library can
do will determine all the basic cryptography.  We have it supporting
des, des3, rc4, and aes today.  We have it working with heimdal & mit.
You'll be able to run with heimdal right off.  MIT is a bit more
problemmatical; no big deal but you probably won't be able to use
vendor libraries at least right off.  We plan to also support openssl,
which might give you the interesting potential for hardware crypto
accelleration of openafs servers such as the fileserver.  The kernel
part links against its own unique self-contained crypto blob; it's
intended to be a fairly fast but very portable.  In the future,
kernel cm's for some architectures may be able to use the kernel
crypto support.  How well that will work will depend in a large
part how "key agile" the kernel interface can be.

Somebody had asked about "fs setcrypt".  For rxkad, that selects
between rxkad_clear & rxkad_crypt.  For rxk5, the same bit will
select between rxk5_auth and rxk5_crypt.  We have code to do "rxk5_clear",
but believe it only makes sense in very specialized circumstances.

For most services, this is true: security index 0 = noauth,
1 = rxvab (extinct), 2 = rxkad, (rarely) 3 = rxkad (crypt),
4 = rxgk, 5 = rxk5.

As for when you might see this, this depends on several things; Matt
and I want to finish a few things up -- mainly "tokens" at this point,
but I might get openssl working too.  The gatekeepers will need to add
it to the repository.  It's possible the next 1.5.x release after that
will have this, but there will in any case be significant work to make
it stable and work on all platforms.  Presumably at some point after
that, there will be an even numbered release (1.6? 1.8?) that has
rxk5.  If you're *desperately* interested in an early peek - drop Matt
or I a line.

				-Marcus Watts