[OpenAFS] my afs wish list

[Derrick J Brashear]

On Tue, 29 Apr 2003, Marcus Watts wrote:

> > clear, auth and crypt. sure. but how do you deal with "type", then, and be
> > backward compatible?
>
> Are you talking "protocol", "software", or "user applications"?

"protocol" or "yes".

> I think you are envisioning some sort of long-term mixed environment
> where keys of different strengths intermingle, and there is a complicated
> algorithm for deciding what to use when.  I think (or at least hope)
> this is much more complicated than necessary.  I envision most keys
> being the same size & type, most users won't fiddle with the defaults,
> and the main question may be whether anything should default to
> network data that is not private (ie, like rxkad_auth).

I think that's an optimistic goal.

> Services that support nmtbnwiy could decide (via application code)
> which levels they support, and could decide separately whether
> to support rxkad or nmtbnwiy, perhaps based on some configuration file
> or option, or simply whether they see a Keyfile or a keytab, and if
> a keytab whether it contains DES, AES, or both.

How do you negotiate?

> Clients will separately need some such mechanism as well.  There is
> already existing logic in clients to deal with rxnull vs rxkad, so
> adding a 3rd should be straight-forward.  (One advantage to sticking
> with the rxkad/shoe-horn approach is that naive clients might not
> need any source changes at all.  If another mechanism is added,
> this advantage goes away, and the constraints with it.)

Without source changes, you can't replace fcrypt.

> I envision most of the "key type" negotiation to happen
> up front, when the user first acquires tokens.  This
> could be in aklog or whatever.

Effectively precluding per-fileserver keys, because otherwise I can't add
a fileserver.

> > See earlier discussion about session versus derived keys.
>
> I don't think it yet matters if it's session, subsession, derived, or
> even individually randomly generated per-packet (like MS RC4).
> Just so long as the various bits of code agree.  But I don't see
> how providing a lot of "choice" in the application is going to
> be of great use.

Nor do I. I think you need to make the "right choice", and making the
"right choice" makes it harder to implement.

> Beats me.  Are we going to burn them at the stake or something?  I

Hey, that would be cool.

> think it started with IBM.  Recent openafs and arla have supported AFS
> k5 tickets, after a fashion -- but only with DES.  I think it's an
> interesting start, but not necessarily the right path.

It's not the right path. It's a dead end, but we needed something for the
eventuality that there was a krb4 problem.

> > Other than the ones we have (which could be better supported)?
>
> This must be recent -- I don't see any such makefile logic in 1.3.2
> (perhaps it's there and not obvious...?) I'm glad to hear they exist.

libafsrpc and libafsauthent also get built as shlibafsrpc and
shlibafsauthent

> I hope there's been some combining of libraries.  Having 20 libraries

There already was before we got the code.

> makes sense when it's all static libraries, but isn't nearly so pretty
> for dynamic libraries.  Also look at heimdal vs. MIT k5 and the mess
> different library naming schemes make there.

Clearly Kerberos needs OpenSSL. Wait, wrong list to be bitter about
that on.