[OpenAFS] fs setcrypt and transarc

[Chaskiel M Grundman]

>> Various people have talked about putting Kerberos V support in afs with
>> support for multiple encryption types, but as far as I know it's just
talk.
> We want one-key-per-fileserver instead of one-key-per-cell,

Even eliminating that requirement doesn't simplify things all that much,
for  several reasons:

1) A krb5 authenticator is a more complicated structure than a krb4/rxkad
authenticator, and requires an asn1-der parser/generator. Putting such a
thing in the kernel seems sub-optimal
2) The way RX is written, it needs to know the session key that will be
used for a connection _before_ that connection's authentication exchange is
performed (because the first packet must be signed/encrypted with that
key). The current conventional wisdom is that using the session key
embedded in the kerberos ticket for session encryption is a bad thing. As a
result, some key derivation/generation mechanism must be used. These 2
concepts don't fit together very well.
3) RX also only allows a single round-trip packet exchange for
authentication. This is good enough for plain kerberos (and even krb5), but
does not allow for key derivation.
4) The people who are doing the work actually want to support GSSAPI, and
not just plain krb5. Since GSSAPI is an abstraction layer, you really don't
know what resources it needs under the covers, or how many round trips it's
going to want. Very messy.


if simply upgrading from fcrypt to des was desirable, it could be done with
about a day of work. The quick hack version would be a little wasteful,
since it would require another security index number to be allocated so as
to provide some amount of backward compatibility. (a few other
improvements, such as better integrity protection, could probably be made
at the same time)

I also believe that support for one individual non-des cryptosystem could
be written in about a week if the following allowances were made: (At one
time, I did propose something like this to the people involved. They ended
up convincing me that it was probably a bad idea.)

1) you'd have to run a gssklog-like program to convert your krb5 tickets
into the tokens this system would use
2) there would be no key-derivation. (the gssklogd-ish thing could generate
a new key seperate from the one in the krb5 ticket, but all afs connection
streams would end up encrypted with that key)
3) all fileservers would still share a key.

This would also consume a security index number, and provides no more
extensibility than rxkad does, so the next new security mechanism would
still require a re-write.