[OpenAFS] Native Kerberos 5 support

[Ken Hornstein]

>Can someone elaborate on this subject. Obviously in the long run people would
>like to see krb5 support for integrating afs with existing krb5 installations.
>So aklog would no longer convert the krb5 ticket into krb4 ticket then get a 
>token with that.
>
>What does rxkad 2b really do? The release notes from 1.2.8 are a little
>vague, and documenation seems sparse.

I'm sure one of the Der{ric,e}ks will correct me if I'm wrong ...

rxkad 2b is sort of halfway between Kerberos 4 and "real" Kerberos 5.

Aklog talks to the 524 ticket converter, but instead of getting back a
version 4 ticket, it gets back a version 5 ticket (the same one it got sent,
actually).  yes, before you ask ... this step could easily be skipped, but
we'd need to keep this around for older versions of aklog, and it's not
clear yet how to tell aklog that some cells are still V4, and some are V5 now
(although with a recent CERT advisory, it's clear that the days of V4
are numbered at a lot of sites).

So, aklog shoves a V5 ticket into the kernel and the V5 session
key.  Now unfortunately since the cache manager only knows about
fcrypt (which has the same key size as DES), you are restricted to
a DES session key.  Now, you _could_ have a 3DES/AES/ArcFour ticket
key, since that would just involve a relatively small change on
the database/fileservers.  But you would still be doing your on-wire
encryption with a 56 bit key even with a longer key in the service
ticket, so it's not a giant win to get a longer key (it would be
a significant win, IMHO, since the service key is more vulnerable
than short-lived session keys, but there are other implementation
constraints).  Right now only DES is supported for the service
ticket as well, and I'm not sure other enctypes will be supported.

--Ken