[OpenAFS] my afs wish list

[Marcus Watts]

Derrick J Brashear <shadow@dementia.org> writes:
> Other people: If this conversation is boring, hopefully you'll at least
> scroll to the bottom for that comment, because I'm pretending it's an
> important point.

Um.  Hope I'm not boring anybody...  (But please, find the nearest
bitbucket and don't mind me if I am, or better yet, let me know...)

...
> 
> > 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
> 
> Sure, that's already true now. Guess how the rxkad 2b (krb5) stuff works?

Yes, I understand just how little the client side code needs to
understand about k5 tickets when fcrypt and des are used.

> > 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.
> 
> Scrapping the kaserver is hard, because lots of people want us to become
> another krb5 KDC vendor. I think the discussion leading up to this point
> states pretty clearly we have plenty that's uniquely ours to solve on our
> plate without looking for solved problems to rehash.

Well, there are some nifty things that kaserver does that are nice,
like ubik replication & automatic tgt rekeying.  But I agree, that's
not an openafs problem and not a reason to keep kaserver around.

> 
> > > > 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!
> 
> Damn right. For departments that want their own AFS server with their own
> disk space, but don't want the overhead of needing to manage accounts,
> that's fine, here's a key, you're in my cell. But, you don't get to
> compromise anything not on your machine.
> 
> It's worse than that when you think about things like volume moves. Let's
> not think about those now.

Yes, those get interesting, especially if you want to constrain who does
volume moves between which servers.

> 
> > 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.
> 
> Sure.
> 
> > 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.
> 
> I have no such expectation.

Whew.

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

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(). ]

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.

I think that's sufficient to support file servers that do AES(128) vs.
DES and to allow for possible future growth for other enctypes, such as
AES256.  It's not sufficient to cover different flavors of AES128.
These don't exist in K5.  So far at least, it doesn't sound like
there's good reason for this to exist in openafs either.

> 
> (*) Well, for a few hours, but that's an impressive feat if you know
> anything about how grumpy I am.

Which reminds me, I'm supposed to be up at 9:30a this morning...

				-Marcus Watts
				UM ITCS Umich Systems Group