[OpenAFS] my afs wish list

[Ken Hornstein]

>> Anyhow, as far as encryption goes, I'm really hoping some of the krb5
>> people will speak up. They have meaningful experience we can draw upon,
>> instead of doing something expedient you could plaster a smile on my
>> face(*) if we did something correct.
>
>Guess I'm just an imitation krb5 person.
>
>As best I can tell, the k5 code that supports multiple DES enctypes
>mainly creates annoying problems and is not well liked.  I would say
>the goal of most current k5 protocol work is to avoid creating any more
>messes like this.  I'm sure Ken Hornstein or others will correct me if
>I'm wrong on this.

Heh.  Well, the multiple-DES enctypes code is rather special case.
The desire was to get rid of the CRC checksum used by the DES cryptosystem
at that time and replace it with MD5.  The problems raised by this were
multiple:

- At the time, the Kerberos code didn't really understand multiple enctypes;
  support was in the _protocol_, but there were plenty of places that assumed
  you were only using once enctype.
- People hadn't really thought out all of the implications of clients/
  application servers/kdcs supporting different enctypes.
- The implementation ended up treating all of the DES enctypes the same,
  which had the unfortunate outcome of not working in many cases, so it
  ended up being nearly impossible to use DES-CBC-MD5 with MIT Kerberos
  for some of the enctypes.  Heimdal ended up being a lot better in this
  regard because all of their code supported DES-CBC-MD5 from the get-go.

Speaking as someone in the middle of a mega-3DES transition right now,
based on my experiences so far the new MIT Kerberos support for multiple
enctypes seems to be ended up alright; you have to understand all of
the implications when you start rekeying services, but it's not too bad.
There are still some things that need to be worked out in the cross-realm
arena, but I think that's not really AFS's concern.

>k5 usually selects session keys based on:
>	a list of encryption types supplied by the client
>	a list of encryption types the kdc supports
>	the list of encryption key types for the principal.
>[ see k5 source: src/kdc/kdc_util.c: select_session_keytype(). ]

Right, it's the "best" enctype based on the intersection of all three
of these things.

>So, the way I see it, there are 2 knobs here that can be used
>to select enctypes for departmental servers:
>	the list of key types for the departmental fs server's principal.
>	the list of key types the "up call" fs service
>		ticket getter advertises.

That's pretty much exactly what I was thinking.  Based on what we've
seen here, this works out pretty well in practice.

I'm not sure what you're going to do when you throw GSS into the mix,
though ... I think the whole "pseudo-mechanisms" that NFSv3 did to
negotiate encryption was a mistake.  I mean, even if you have a 3DES or
AES GSS-API (which is tough enough as-is), you're still stuck with
DES-CBC-MD5 for encryption.  At least they fixed that in NFSv4.  I know
I'm in the minority here, but I personally think using GSS-API for AFS
would be a mistake, since you're going to have to embed so much
Kerberos-specific knowledge (at least on the client) that you don't
actually get any of the "generic" benefits to GSS-API (and you make
everything else harder in the bargain).

--Ken