[OpenAFS] my afs wish list

[Marcus Watts]

Derrick J Brashear <shadow@dementia.org> sent:
> From: Derrick J Brashear <shadow@dementia.org>
> To: Marcus Watts <mdw@umich.edu>
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] my afs wish list 
> In-Reply-To: <200304291926.PAA11654@quince.ifs.umich.edu>
> Message-ID: <Pine.LNX.4.53.0304291608520.3614@scully.trafford.dementia.org>
> References: <200304291926.PAA11654@quince.ifs.umich.edu>
> 
> On Tue, 29 Apr 2003, Marcus Watts wrote:
> 
> > > But the problem is the concept of rxkad "levels" loses meaning if you try
> > > to extend them. Like, a mechanism that provides stronger integrity than
> > > what we have now, but no encryption, will necessarily be a higher level
> > > than rxkad_crypt. How do you do ordering? How do you do a minimum?
> > >
> > > For that matter, how do you do the security exchange?
> >
> > Seems to me that rxkad "levels" are orthogonal to encryption type.  I
> 
> 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"?

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 don't think anybody actually uses "rxkad_clear" - it looks like
sort of a placeholder for "noauth", which effectively works as
a different security mechanism altogether.  So we already have
effectively more than one dimension:
	mechanism	noauth	rxkad
	type		noauth	clear
			-	auth
			-	crypt

Obviously, if it's not rxkad, the field is wide open for all 3,
and the main question is what *should* it be and does one small
integer give all the desired flexibility?  I think it could look
as simple as this:
	mechanism	noauth	rxkad	nmtbnwiy
	type		noauth	clear	-
			-	auth	authonly
			-	crypt	private
(nmtbnwiy = the mechanism to be named which isn't yet)

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.

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

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.

I envision most of the rxkad/nmtbnwiy level type stuff to happen
inside applications and services, and to happen mostly quite invisibly
to users.

If "2 levels" of integrity checking aren't enough, I'd love to
hear of others and why they are also necessary.

> 
> > think they're a nice idea, and that it doesn't hurt to support having
> > authentication and integrity checking without necessarily paying the
> > overhead for privacy too.
> 
> 
> > I don't think I'd want to confuse this at all with encryption type.
> > Doing the security exchange seems simple.  I'd let the KDC deal with
> > it.  If client code gets a KDC ticket that has an AES session key in
> > it, then it should do AES.  If client code sees a KDC ticket that has
> 
> 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.

> 
> > protocol, and deciding it made more sense to just replace rxkad.  Since
> > then I see some people have had luck teaching rxkad about k5, which
> 
> which people are those?

Beats me.  Are we going to burn them at the stake or something?  I
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.

> 
> > thing that stopped me was what to name a replacement.  "rxkad" has a
> > nice ring to it.  "rxrc6" or "rxaes" or "rxk5ad" don't seem nearly as
> 
> "rxis" or "rxes" would be pronounced "Rexis", what it stands for is an
> exercise for the reader.

Uh yes.  Pharmacy RFP (RX) issuing states.  And X-ray emission spectra.
Ah, the evils of google.  ;-)

> 
> > pronounceable to me.  Ok, so this is a silly thing to worry about.
> 
> > (granted, a *big* pain -- would be nice to see shared libraries
> > come out of this too.)
> 
> 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.
I hope there's been some combining of libraries.  Having 20 libraries
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.

					-Marcus