[OpenAFS] my afs wish list

[Derrick J Brashear]

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.

On Tue, 29 Apr 2003, Marcus Watts wrote:

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

Oh, well, sure, if you change the scope of your comment;-)

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

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

I'd argue no, but more on that shortly.

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

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

Yuck.

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

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

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.

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