[OpenAFS] my afs wish list

[Marcus Watts]

Derrick J Brashear <shadow@dementia.org> writes:
> From: Derrick J Brashear <shadow@dementia.org>
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] my afs wish list 
> 
> 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.

Sure you can.  (Er, without client program changes that is).  Whether
the library is secure or pretty is another question.  User programs
don't generally know exactly where tokens come from, what size they
are, or where they're going.  Most of that is hidden in various
libraries, and there's not much that knows what's in a
ktc_encryptionKey.  So, add a "type" and "length" key, and set data to
contain the max sized key.  That should suffice for things like
	ptserver/ptuser.c
which just calls rxkad_NewClientSecurityObject after getting a token
using perhaps ktc_GetToken, or avoids the whole issue by calling
afsconf_ClientAuthSecure.

At this point, the remaining client side changes are mostly confined in
rxkad.  Mostly that means teaching rxkad to use fcrypt + something
else, depending on the new type field in encryption keys.
Etc&etc&etc.

Now, whether that's a good idea or not is another question.  There may
very well be good wire protocol reasons why rxkad isn't a good idea;
the small checksum sizes certainly bother me.

Lots of trivial problems remain too, like scrapping kaserver, dealing
with bos, messiness in the cache manager and token cache, etc.  So
there are certainly some client changes that are unavoidable.

Here's another idea though: keep the rxkad client interface; and stuff
a new wire protocol on the back end of rxkad so that it actually
supports 2 protocols.  Messy.  I don't think it's worth saving the work
to change client side code.  But it's possible.

> 
> > 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.

Ah!  That's the flexibility you want!

Right.  To do that, you either need to get all tickets ahead of time
or have some sort of kernel upcall or some sort of ticket acquisition
"on demand", after the hypothetical new fileserver gets added.

If you have to get a new ticket, then the keys in the kdc can still
drive what the client talks.  If you somehow expect to get new
tokens without getting a new ticket, then you are creating some sort
of kdc-within-a-kdc, or perhaps doing something interesting with pki.

				-Marcus Watts
				UM ITCS Umich Systems Group